[OPEN-ILS-GENERAL] Proposal to change Evergreen versioning scheme

[Sharp, Chris]

Hi all,

I'm not sure the numbering scheme matters that much to most people currently using Evergreen, but I do have a couple of responses to points made so far:

> Issues with the current versioning scheme:
> * The current scheme is code-centric, complicated and not generally
> useful: http://www.open-ils.org/dokuwiki/doku.php?id=versioning

It actually looks pretty standard to me in comparison to other F/LOSS projects.

> * The current scheme creates a perception that Evergreen is
> stagnating - version 2 since 2010

I don't agree with this.  It took years and years for the Linux kernel to move from major version 2 to major version 3, for instance, and no one thinks it's stagnating.

> * Under the current scheme Evergreen will reach version 3 in 2016(!)

I don't see this as a problem...

> On the subject of numbered releases in general: I think we should
> ditch them entirely and tell people to run out of git. I also
> understand that is not likely to happen, but I am saying it anyway.

Anyone who pays attention to IRC discussions knows my take on this, but numbered releases are important for organizations that need to move more slowly than the developers as far as feature additions and changes to core functionality go.  The main issues around this are the following:

1) end user documentation and training - organizations that support a large consortium of diverse libraries need some solid ground to develop and implement training and documentation for end users.  If the software is constantly changing, documentation and training content grows stale fast, and we can't spend all our time playing catch-up
2) technical support staff - we need to have a good handle on how the software is "supposed" to work - if that's changing constantly, that's not (as) possible to do
3) frontline staff and patrons - our users become very frustrated and anxious with what appears to them to be arbitrary change.  In our case, we'd like the software to just serve the purposes it's meant to serve without being the main focus of public library staff's daily work.  That would not be possible if we were streaming in new features as they are developed.
4) related to the above points, we do not want our production system to be a testbed for new features

Version numbers also help system administrators know which features/bugfixes/etc. are in which release.  See my comments on this bug regarding the currently unversioned SIP Server: https://bugs.launchpad.net/sipserver/+bug/1083290.

> Even *with* the numbered releases I think we should ditch tarballs
> and point people at git *anyway*, for that matter. Which is another "not
> likely to happen" thing.

As long as the tagged git version and the tarball match, I have no problem with suggesting either, but I think tarballs are standard and expected in F/LOSS projects.

> On the subject of the proposed scheme: I disagree with the last digit
> of the year. If we are going with any form of date-based numbering
> then I think we should go for last 2 digits of the year with the
> second number being the month. The third number would start with 0
> and increment once for each maintenance release.

> If we decide to change, I would also vote for the Ubuntu-style naming
> scheme Thomas describes. (IIRC, Jason S. was also a proponent of
> this scheme).
> 
> As an example, the next release would be the 13.03.0 release.

+1

Chris


-- 
Chris Sharp
PINES System Administrator
Georgia Public Library Service
1800 Century Place, Suite 150
Atlanta, Georgia 30345
(404) 235-7147
csharp at georgialibraries.org
http://pines.georgialibraries.org/