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

[Lazar, Alexey Vladimirovich]

On 2013-01-04, at 14:52 , 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.

I agree, and it is unlikely that we ever will.

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

So do I, it really makes sense. However, assuming that Evergreen's declared versioning scheme was not maintained due to additional time required to manage it, this too may not work too well.

> 
> 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 was done. Now I think it would be a good idea to formalize how the process of determining "new major features" works. Will this be decide by the release manager?

> 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 agree that would be confusing. If this scheme were adopted, the version number should stay static based on the release schedule, and not the actual release date.

> 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 agree and would like to offer my help with this, however, not sure exactly how at this point.

> 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

Yes. In the second paragraph on http://libmail.georgialibraries.org/pipermail/open-ils-dev/2012-May/008237.html, I touted my suggestion for hands-off scheme as a type of a solution for this.

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

Yes, but someone still has to decide what constitutes "major feature updates". So, this change does not really eliminate future discussions about whether or not to increment version numbers. Also, major feature updates have occurred since version 2, but the version numbers stayed the same. So, should the next version be 3?  

Aleksey Lazar
PALS
IS Developer and Intergrator
507-389-2907
http://www.pals.org/
alexey.lazar at mnsu.edu