Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

During Developer Meetings on 2011-11-09 and 2011-11-16, we decided that the next DSpace Release in Fall 2012 will be called 3.0

Thoughts on Version Numbering

This page is a "placeholder" for all suggestions around renumbering our DSpace releases. Our current version numbering convention is documented in our Release Procedure at DSpace Numbering Convention

Overview - Why is this even being discussed?

In recent and past Developer Meetings, the topic always comes up: "I'd like to suggest we change our DSpace version numbering from the 1.x.x (e.g. 1.6.0, 1.6.1, 1.7.0, etc.) numbering we currently use." (See DSpace Numbering Convention, for more info on our current version numbering convention)

Usually this comes out of a few perceived issues with our current numbering sequence (whether or not these are just misperceptions, or are actual issues is up for constant debate):

  1. All the "baggage" around the idea of DSpace 2.0, and wanting to avoid that in the future. The version "2.0" has been mentioned off and on for 5+ years as the "next, amazing version of DSpace". Therefore "DSpace 2.0" is sometimes perceived to have a lot of expectations around it (especially in terms of what features it must have to be considered "2.0").
  2. The potential misperception that "1.x" versioning sounds like DSpace may not be as mature or stable as it really is. Obviously DSpace has been around since 2002, and has over 1000 institutions using it worldwide (which speak to the maturity and stability of the system). But, some may feel higher numbered releases sound as though they are more mature.

The Case for Date Based Version Numbers

So what do we mean by a date based version number? It's when the date of release forms part of the product identification - like Windows 95, or Windows 98. Or, more usefully in our case, Ubuntu's numbering scheme where the major number is the year, and the minor number the month. Which gave us: 10.04 (released April 2010), 10.10 (released Oct 2010) and the forthcoming 11.04 (to be released April 2010). For DSpace, it would make the next release 11.10.

Why should we adopt this scheme? Aside from the reasons given above (which are applicable to all alternative schemes), there are advantages to date based versioning:

  1. It's a logical change - ie. you can see that the change is numbering scheme is clearly meant to reflect something specific, and not just an arbitrary chosen value.
  2. Promotes the view of DSpace as an evolving platform (as opposed to the revolutionary / evolutionary cycles of standard major / minor release numbers)
  3. It's clear how old your version of DSpace is without looking it up. In 2020, I'll be able to immediately tell you when DSpace 11.10 was released. How quickly can you answer that question for DSpace 1.4.1?
  4. Reinforces the process of time-based releases, and favours a predictable schedule for subsequent (major) releases

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....

This seems to me like an ideal candidate for convergence with other members of the duraspace community. Differing to a wider policy both stops the conversation and is says a lot about the our future plans for the project as a whole. (stuart yeates)

  • No labels

2 Comments

  1. Aaron Birkland

    I am a Fedora committer, and do not know much about the DSpace release process - but this topic looked interesting. Here are a few thoughts/questions:

    With regard to date-based versioning like Ubuntu, how will that interact with maven, and the published artifacts therein?

    • With Ubuntu, any particular version number (say, 10.04) does not really refer to any one single deterministic set of "artifacts" if you consider the constant stream of updates/fixes of constituent packages. Does DSpace operate in the same fashion (one release version, constant stream of updates), or does it issue (and deploy to maven and/or download sites) a distinctly versioned point release when one of its constituent modules is updated? If so, what would the version numbers of the DSpace release and/or its modules look like under date-based versioning? Something like 10.04.20, or even 10.05.09?  If so, is it important to distinguish the "main" release from any "bugfix" releases after it any more?   If so, how? 
    • Sometimes the maven release plugin can be troublesome with anything "not standard" Will a date-based versioning scheme play nice with the release plugin?

    From the Fedora perspective, so far major.minor.point has worked well for us - we've been lucky enough to have sufficiently obvious "major" architectural milestones that so far in moving from version 1 to 2 to 3. Moving between major versions has typically required some sort of export or format migration of the data itself. Minor versions have introduced new features, API Methods, introduced deprecations, or required rebuilds of internal indexes. Point releases have been typically been "essential" fixes for issues that that put security, data, or access at risk.

    I remember NetBSD went through something like this several years ago. At the time, they had been on a 1.x series for almost a decade. In the end, they decided to simply release major versions approx. every year (though I don't think it stayed that way, exactly).

    1. Mark Diggory

      I think I'm more interested in getting even more ganularity into the version numbering.  To answer your question about how that would impact maven. please take a look at the numbering scheme I've been working on for asynchronous release. Asynchronous Release  Here, the goal is to create two tiers of versioning... the DSpace release number (in this case 8.0) and individual module versioning that is more granular (8.0.1).  I keep being indecisive about date based numbering.  I think it would provide a clear separation between module versioins vs the DSpace version.

      I wonder if the appropriate path forward for async release would be to first attempt the separation of numbering (year.month for dspace assembly) and individual numbers (1.8.0) for the modules. This would set the stage for async release and minor update release of modules without wholly confusing everyone.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.