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