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

[Lori Bowen Ayre]

For those of us not up-to-date in our Order Theory studies, would Galen
care to explain what monotonically refers to in this discussion.

Intrigued in Petaluma

On Fri, Jan 4, 2013 at 10:04 AM, Rogan Hamby <rogan.hamby at yclibrary.net>wrote:

> I'm not sure I agree that version numbers aren't important to marketing
> Evergreen.  Non-techie administrators have been trained to see large
> numbers before the dot meaning that there should be a lot of major features
> and that small numbers after it means that those features are mature and
> bug tested and that if they go to a new major dot release that they should
> be prepared to do a lot of training.   I am continually marketing Evergreen
> upgrades to my existing Evergreen directors and would like to get them on a
> twice a year upgrade schedule with the new releases.  So long as they are
> .x upgrades I think I can convince them of that.  X.x releases where it's
> moving to 3.0 or 4.0 I know will invoke major concerns for the training and
> preparation time.  This is a short hand used by people who don't understand
> the release notes sometimes to get an indication of how much effort their
> front line staff will have in adapting to it.
>
> If we move to a new versioning scheme I just want it to have enough of an
> advantage that it will be worth re-educating people who can't follow the
> discussion that's on this list.
>
> But I do want to give a +1 to Galen on general principle of using the work
> "monotonically" as I will anyone who uses a term from order theory.
>
>
> On Fri, Jan 4, 2013 at 11:41 AM, 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 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.
>>
>> 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.
>>
>> [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.
>>
>> Regards,
>>
>> Galen
>> --
>>
>> Galen Charlton
>> Manager of Implementation
>> Equinox Software, Inc. / The Open Source Experts
>> email:  gmc at esilibrary.com
>> direct: +1 770-709-5581
>> cell:   +1 404-984-4366
>> skype:  gmcharlt
>> web:    http://www.esilibrary.com/
>> Supporting Koha and Evergreen: http://koha-community.org &
>> http://evergreen-ils.org
>>
>
>
>
> --
> ----------------------------
> Rogan Hamby
> Headquarters Manager, York County Library System
>
> "You can never get a cup of tea large enough or a book long enough to suit
> me."
> -- C.S. Lewis <http://www.goodreads.com/author/show/1069006.C_S_Lewis>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20130104/24898bf2/attachment-0001.htm>