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 <[email protected]>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 <[email protected]>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 >> <[email protected]>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 <[email protected]>wrote: >>> >>>> Hi, >>>> >>>> On Fri, Jan 4, 2013 at 7:07 AM, Bill Erickson <[email protected]>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: [email protected] >>>> 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: [email protected] 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
