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

[Dan Scott]

On Fri, Jan 04, 2013 at 03:21:08PM -0500, Rogan Hamby wrote:
> I would disagree.  It's not this one:
> http://www.open-ils.org/dokuwiki/doku.php?id=versioning
> 
> But, I would propose that we are following one based largely on the
> developer's perception of what are major and minor features and impact for
> users.  I've been there for a few of those discussions and those were the
> concerns voiced when discussing version numbers.  Unintentional?  I can't
> speak to that.  But, to me what is already being done, as abstract and ill
> defined as it is (and I think that is part of what bothers some) - works.
>  I'm fine with things as they are.  It works with the larger community's
> goals (or at least mine) and a raw number means something to the front line
> users.

If we had a marketing team, and they had done some research that showed
that version numbers actually matter when it comes to perceptions of a
library system's stagnation (or not) and adoption of said system, then I
would defer to their decision. But as far as we know, we don't have a
marketing team, and I haven't seen any citations about such research on
generic software products in the discussion to date.

On the argument that we're not following our current versioning scheme
criteria around the major number - I like James' pointer to the semantic
versioning proposal, and that fits quite well with library
versioning semantics that we're already doing (to some extent) via
autotools.

That said, given that some major piece of infrastructure is likely to
always change (Dojo or PostgreSQL or XULRunner or Apache or any of the
other umpteen dependencies that we have), we could either strike the
pertinent clauses from the versioning scheme in the wiki, or alter it to
say that it will be incremented when major features are added.

As someone who is (currently very slowly) working towards packaging
Evergreen, I would much prefer version numbers and tarballs to just
pulling directly from git. Tarballs are a much lower barrier to entry
and having a release artifact means that (in theory) the people testing
the release candidates are all testing the same base code, without
differences based on their local version of tools that generate the code
that is in the tarball and not in git.

I don't like the date approach very much as, although we've agreed to
time-based releases, we've also agreed to let the release date slip if
there are known blockers. So we could end up with 13.04 / 13.11 / 14.05
/ 14.10, and that would lead to references to 13.10 having to be updated
in multiple places to 13.11 if we slip. Bah.

I think a lot of the "Is it going to be a huge pain to upgrade? Or is it
just a minor upgrade?" angst would be diminished if we (devs and release
managers) did a better job of communicating expectations about each
upcoming release. We pledged to do this at EGConf 2012 and had a good
start, but need to stay vigilant on this front - and pitch in on the
documentation (release notes & upgrade notes).

I will admit to suffering from fatigue around this discussion, which
last came up in May:
http://libmail.georgialibraries.org/pipermail/open-ils-dev/2012-May/008203.html

In the end, I'd really like to not have this discussion come up on a
regular basis. There's code and docs and tests and websites to be worked
on, and a product that is solid and reliable and easy to understand and
use is going to succeed no matter how much the version numbers diverge
from the scheme documented on a wiki page. And if the current problem
can be rectified by striking out two clauses from the wiki page, why
don't we just do that so we can focus on everything else we have to work
on?