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>
