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 <[email protected]>:
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"
<[email protected]> 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/
[email protected]
