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

[Rogan Hamby]

Just to play devil's advocate one man's stagnation is another man's
stability.  Trust me, I have plenty of folks that would love to see just a
stream of tiny little releases that didn't rock the boat any.  It's
dangerous to say what the whole community thinks without a lot of research,
which kind of speaks to Dan's point.  I'm hesitant to make decisions
because I feel it's obvious a large number of people I never hear from feel
a certain way.

(As for upgrade angst, I want to run off daily and not bother with
versioned releases and if it was just my library I would, but I have a
bigger fish to deal with.)


On Fri, Jan 4, 2013 at 3:52 PM, Dan Scott <dan at coffeecode.net> wrote:

> 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?
>



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