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.ha...@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 <g...@esilibrary.com>wrote: > >> Hi, >> >> On Fri, Jan 4, 2013 at 7:07 AM, Bill Erickson <ber...@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: g...@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> >