SUNScholar/Software Release Cadence

Back to Guidelines

Back to Repository Preservation

Keep it simple, stupid (KISS)

Introduction

This wiki page is related to a posting on the DSpace general mailing list, see link below.

http://sourceforge.net/p/dspace/mailman/message/31894819/

The Problem

We run one of the larger repositories with 55,000 records and about 10,000 full text items. We also have a large admin and normal user base after two years operation. So although the demo DSpace website may work, things change radically in production environments, when doing version upgrades, not fresh installs, and having many records and users.

The Solution

Some very large production institutions who have the full technology support stack available can be the "official new release testers" for new features for a certain amount of time, before a "stable" release is issued. This is if they are willing to do it to help the community. The issue is to test new features in large production environments with all types of reference architectures before a stable release is announced.

This could suit DSpace very well, in creating a stable, reliable and trusted solution.

Those institutions that do not employ a full technology support stack, could then safely run the stable version of DSpace. This would also help libraries in developing nations that do not normally have a full technology stack of expertise at their disposal to run the latest "stable" version of DSpace.

Possible Action

Perhaps a resolution could be made to the DSpace/Duraspace community management to change to such a release process. This would allow new features to land in DSpace safely after being thoroughly tried and tested in large production environments.

References

• https://wiki.duraspace.org/display/DSPACE/DSpace+Software+Support+Policy