Page History

...

An example may be the best way to understand this idea! What I'm talking about is the following sort of release process

Example, Completely Hypothetical Release Scenario
(I've randomly chosen to call this hypothetical release DSpace "11" so that it has no real meaning or implications. I could have just as easily called it DSpace "2011" or DSpace "Mountain Lion".)Example, Completely Hypothetical Release Scenario

1. Suppose we were to release a DSpace "11.0" which includes a new features in our "Core Infrastructure APIs". It also comes with a pre-packaged 11.0 version of our "centrally supported UIs": XMLUI, REST, SWORD, Solr Stats, Discovery, and WebMVC (This is a hypothetical listing of "centrally supported UIs")
2. A third party team may release their own Ruby on Rails or PHP DSpace interface which is "compatible with DSpace 11.0". This code is managed/supported external to the Committers group (and may or may not exist in the central DSpace SVN).
3. Suppose 1 month later, we realize a significant issue in our 11.0 version of SWORD (maybe we didn't properly follow the latest specifications). Therefore, we immediately release a 11.1 version of SWORD asynchronously, and provide "easy install/update instructions" for those who want this immediate SWORD fix. (We could also call this bug-fix release of SWORD "11.0.1" – the main idea here is that we are able to release the SWORD module on its own, for those who want an immediate fix to just that module.)
4. Suppose a month or so later we realize we also have some XMLUI bugs/issues we'd like to get a fix out for. So, we release an 11.1 version of XMLUI asynchronously, for those who want these immediate fixes. (Again, this bug-fix release of XMLUI could have also been called 11.0.1 – the main idea is that now we have also released an updated XMLUI module separate from the "core" of DSpace)
5. Now, it's a few weeks later an we suddenly realize there's a small bug in one of our "Core Infrastructure APIs/Modules", which may affect all/most of our interfaces. Now, we decide to release an official DSpace "11.1" release – this includes updated fixes to the Core Infrastructure API (now versioned 11.1), along with pre-packaging of the same SWORD (see #3 above) and XMLUI (see #4 above) fixes we already released before. We also release updated 11.1 releases of each of our other "centrally supported UIs" (see #1 above). We send out an announcement encouraging everyone to upgrade to this official DSpace 11.1 release.
6. It's now 6 months or a year later. We decide we're ready for our next major release, DSpace "12.0". This new release adds new features to the Core Infrastructure APIs, so we release it as the next major version of the software platform (11.0 -> 12.0). These new features are also now enabled in updated 12.0 versions of our "centrally supported UIs": XMLUI, REST, SWORD, Solr Stats, Discovery, and WebMVC.
7. The same third party team who developed a Ruby on Rails or PHP interface for DSpace (see #2 above) now may release a new version which is "compatible with DSpace 12.0". Or, maybe they haven't gotten to that version yet, and they only have their interface updated to be "compatible with DSpace 11.1".
8. Finally, the process begins again...we can release 'bug-fix' versions of modules early as we locate bugs, and also package up a larger formalized 'bug-fix' release (if we deem necessary, or if Core Infrastructure APIs are affected).

...