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

[Rogan Hamby]

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/ad8ed80b/attachment.htm>