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

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)