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

[Thomas Berezansky]

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.

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.

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.

Thomas Berezansky
Merrimack Valley Library Consortium


Quoting Justin Hopkins <justin at mobiusconsortium.org>:

> Why are we so focused on the numbering scheme? I don't think the time
> spent worrying about what number we are on does anything to improve
> the project.
>
> I suspect this is coming up because of bericks recent post about
> release scheduling - which I (personally) do think would improve the
> project.
>
> Regards,
> Justin Hopkins
> Manager, Information Technology
> MOBIUS Consortium Office
> c: 573-808-2309
>
> --sent from a mobile device--
>
> On Jan 3, 2013, at 5:35 PM, "Lazar, Alexey Vladimirovich"
> <alexey.lazar at mnsu.edu> wrote:
>
>> Hello.
>>
>> I would like to propose a change to the official Evergreen  
>> versioning scheme. Rather than then the current scheme that  
>> attempts to tie version numbers to various code changes, I propose  
>> that we switch to a more simple and predictable calendar-related  
>> scheme that better aligns with the new release schedule.
>>
>> 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
>> * More importantly, the current scheme is not being followed as described
>> * The current scheme creates a perception that Evergreen is  
>> stagnating - version 2 since 2010
>> * Under the current scheme Evergreen will reach version 3 in 2016(!)
>>
>> I am proposing a scheme that would tie major version numbers to the  
>> last digit of the current calendar year. Under the new scheme, the  
>> next major release version would be 3, which I will use for  
>> examples below.
>>
>> Option 1:
>> * The first major release of the year would be 3.0, the second  
>> major release would be 3.1.
>> * Minor releases: 3.0.1, 3.0.2, 3.1.1, 3.1.2 and so on
>>
>> Option 2:
>> * The first major release of the year would be 3.1, the second  
>> major release would be 3.2.
>> * Minor releases: 3.1.1, 3.1.2, 3.2.1, 3.2.2 and so on
>>
>> Option 3:
>> * The first major release of the year would be 3.4, the second  
>> major release would be 3.9
>> * Minor releases: 3.4.1, 3.4.2, 3.9.1, 3.9.2 and so on
>>
>> So, just wanted to throw this out there, again [1], to see what  
>> people think.
>>
>> My proposal is based on this post by Bill Erickson and the  
>> discussion that followed:
>> 1.  
>> http://libmail.georgialibraries.org/pipermail/open-ils-dev/2012-May/008203.html
>>
>> P.S. Should this scheme be adopted, the next version is an  
>> excellent opportunity to switch to it smoothly. However, I would  
>> like to suggest that it is time to jump to version 3 regardless of  
>> whether the versioning scheme is changed officially.
>>
>> Aleksey Lazar
>> PALS
>> IS Developer and Intergrator
>> 507-389-2907
>> http://www.pals.org/
>> alexey.lazar at mnsu.edu
>>
>>
>>
>