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]
