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

[Lazar, Alexey Vladimirovich]

On 2013-01-04, at 09:49 , "Sharp, Chris" <csharp at georgialibraries.org> wrote:

> Hi all,
> 
>> * 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.

I would argue that Evergreen is different from the Linux kernel in the sense that a much wider audience, from library directors to developers, deals with Evergreen directly. That is not true for the Linux kernel. 

> 
>> * Under the current scheme Evergreen will reach version 3 in 2016(!)
> 
> I don't see this as a problem…

It is not a problem per se, except if perceived as stagnation by those who are not following Evergreen development closely

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

I could not agree more.

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

Different subject, but I read through the bug and agree that it would be a good idea to number SIPServer releases. I was a bit surprised to find it was not the case already.

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

I think it may be too early to ditch tarballs completely. I would like to see Evergreen packaged and installable from linux distribution repositories before that occurs. 

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

Aleksey Lazar
PALS
IS Developer and Intergrator
507-389-2907
http://www.pals.org/
alexey.lazar at mnsu.edu