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

[Galen Charlton]

Hi,

And in this case, the order being determined by time.  In particular, if we
were to adopt Ubuntu-style version numbers and release a 13.04, that it
would be a niceness to not pull a Windows and decide next year to release
4.0.

Regards,

Galen


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

> I can't speak for Galen but I inferred he was using it in the context of a
> increasing sequence (rather than say decreasing which would make no sense
> here) and monotonically means preserving the order for the members of a set
> of values.  I.e., it keeps order for the increasing versioning numbers in a
> logical ways by the set rules rather than being random or arbitrary.  There
> are a few more points for the calculus crowd in there but I was an English
> major so I don't know nuthing about that.  :)
>
>
>
>
> On Fri, Jan 4, 2013 at 1:29 PM, Lori Bowen Ayre <lori.ayre at galecia.com>wrote:
>
>> 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>
>>>
>>
>>
>
>
> --
> ----------------------------
> 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>
>



-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20130104/79c01c8b/attachment.htm>