Page History

...

The last point does also provide one possible disadvantage - if we ever wanted to back away from time-based releases, a date based version number would be impossible to pre-announce before it's clear when the release would take place (but we could always use codenames for development announcements).

Date Base Release Versioning with separate individual addon version numbering.

This would augment the above strategy with the ability to version individual modules (dspace-api, dspace-stats, dspace-discovery) with thier own version numbering (1.8.1, 2.0.0, N.N.N).  There are further details on this here Asynchronous Release

The basic principle would be that the dspace/trunk/dspace directory would become the project that was versioned with the dated number (11.10) This may or may not ever reach a point of being placed into the Maven repository, as it is used as the assembly point for the application. (On a tangent, actually creating artifacts for the configuration sources (config,etc,solr) would enable us to start to create Maven archetypes for starting a DSpace build rather than downloading source releases)

Likewise, dspace-parent would go away and we would rely on dependencyManagement to be handled in the dspace/trunk/dspace/pom.xml such that the build/deployment has direct control over it at assembly time.. Using dspace-pom instead of parent allows us to release indivudal releases of dspace-api, dspace-xmlui, dspace-stats, etc When we then have the ability to release these separately, maintenance releases can simply be resolving the latest version of a maven artifact from the repository (via dependencyManagenet in the dspace/pom.xml ) rather than having to actually upgrade the dspace/modules/*/pom.xml files to newer versions of the dependencies.

This actually turns our maintenance release process into more of an "update" to your currently configured build rather than a merging of sources.  As long as customizations are maintained in dspace/modules and all that is required to update your release is incrementing the version number in your dspace/pom.xml dependencyManagement, then minor updates can be released much more frequently than 2-3 time a year, for instance, all the recent fixes on the dspace-1.7.x branch could have been release incrementally and actually be in effect on the DSpace 1.7 release already.  This is why I think this will be such a powerful approach.

Please add your own proposals on version numbering here....

...