[OPEN-ILS-GENERAL] ***SPAM*** Re: Proposal to change Evergreen versioning scheme

[Lazar, Alexey Vladimirovich]

On 2013-01-04, at 10:41 , Galen Charlton <gmc at esilibrary.com> wrote:

> Hi,
> 
> On Fri, Jan 4, 2013 at 7:07 AM, Bill Erickson <berick at esilibrary.com> wrote:
> 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). 
> 
> All that I ask of a version number that it increase monotonically, not be unreasonably long, and that if there are any semantics attached to the version numbering scheme that set expectations for ease of upgrades [1], that they be adhered to.

I am actually neutral on whether or not we use a Ubuntu-style versioning scheme specifically, e.g., using the last two digits of the year. I proposed to use a scheme based on last digit of the year specifically to provide a natural monotonically increasing path to make a transition to a calendar-based versioning scheme from current 2 to 3.

> 
> I have no objection to switching to an Ubuntu-style scheme (so if we're voting, consider this a 0), though I would also point out that doing so means that we would lose the ability to increment the version number significantly to signal a truly major new release.  For example, without reading the release notes, there would be nothing to indicate whether (say) Evergreen 13.10 adds just a few nice features over 13.04 or if it adds two new major functional modules.

I agree this is a valid concern. However, many new features and significant changes have occurred to Evergreen since version 2.0 and the version was not incremented. So, even though this is a valid concern, perhaps this is more of a theoretical than practical loss at this point.

> 
> That said, I don't think that version numbers are of that much consequence in marketing Evergreen -- the advent of major new features  (serials! acquisitions! robotic book returners!) matters rather more to library staff who are anticipating an upgrade.

I agree that major new features are the "meat" of marketing Evergreen to new libraries, but I also think that having *some type* of a steady progress in version numbering also helps on some level.   

> 
> [1] For example, the PostgreSQL project's policy at http://www.postgresql.org/support/versioning/ specifies that minor release upgrades will never require a dump/restore of the database.

Speaking purely as my opinion, I think that having stable long spans of time between major database versions of PostgreSQL is sort of useful for sanity of DB admins and those who write and maintain software that depends on it. Also my opinion is that for PostgreSQL specifically, it is far more crucial to maintain a strict versioning policy that is tied to backward compatibility, among other things, because many systems and software depend on those features. Evergreen does not really have any other software depend on it in the same fashion.

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