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

Justin Hopkins justin at mobiusconsortium.org
Fri Jan 4 17:38:50 EST 2013


I think Dan hit the nail on the head, especially with his first and last 
paragraphs.

Justin Hopkins
Manager Information Technology
573-808-2309

On 1/4/13 2:52 PM, Dan Scott 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?



More information about the Open-ils-general mailing list