[Koha-devel] Version numbering, starting a discussion

[Fischer, Katrin]

I think changing our numbering scheme will only cause more confusion than it will help. Perhaps we should have an explanation somewhere in the wiki – but the current numbering is logical and has a lot of important information.

-- Katrin


From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Ian Walls
Sent: Thursday, December 01, 2011 1:46 PM
To: MJ Ray
Cc: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Version numbering, starting a discussion

The way I've seen version numbering is in 4 parts:

<major version>.<major release>.<maintenance release>.<DB rev>

Major version has at yet been a single digit, but should we get up to major version 9, we'll probably just roll on to 10.  It only changes when there are significant reworkings to the internal mechanisms of Koha.

Major release is two digits, zero-padded, incrementing by 2 each time, off-set by 1 for development versions.  I think the major confusion factor here is the zero-padding.  Koha 3.6 and Koha 3.06 are the same thing, but people often confuse 3.06 with 3.0.6, which is a significant difference!  Major releases come out every 6 months, now, and I hope that practice will continue.

Maintenance releases are also two digit zero-padded values, incrementing by 1 each time.  This is done on a strict monthly schedule, and keeps any major release fresh.  We rarely get far past a single digit, just given our end-of-life patterns so far, but it can happen.

The DB rev is really only for developers or those who follow the master branch.  In the absence of the formal maintenance release notes, it gives one an idea exactly what features and bug fixes are included in the software they're running at the moment.   This takes form of a 3 digit zero padded value, incrementing by 1 for each change to the database structure or default data.

I think this schema works pretty well.  The major hiccup I see the zero padding in the major release causing confusion.  There is of course confusion introduced by other folks with a similarly-named software package trying to 'one-up' the current Koha version, but that's out of our control, and in my opinion not worth changing our practices over.

One possible counter-proposal:  instead of just numeric releases, what if we started given them names, as well?  Something in a theme agreed upon by the community (Liz Rea and I discussed 'cheeses' as a possible theme, once).  About 3 months before the next release, the community solicits ideas for names.  Once gathered, we vote.  Just an idea :)

Cheers,


-Ian
On Thu, Dec 1, 2011 at 5:40 AM, MJ Ray <mjr at phonecoop.coop> wrote:
Paul Poulain <paul.poulain at biblibre.com>
> === DB update numbering === [...]
> What do you think of this idea ? Why should we keep the previous
> numbering scheme ? Any other suggestion ?
It doesn't really matter, so go with whatever's easiest to manage,
but if you go back to plain numbers, I suggest starting from 4 so
that it is still bigger than 3.7.whatever in one sense.

> === Koha version numbering === [...]
> This question arise because some of our libraries have problem
> understanding what will be the next version number. It will be 3.8. And
> the next one ? 3.10 or 4.0, depending on Solr or any other major change
> being applied. And maybe, in april, Solr will be pushed, in this case it
> would be called 4.0 (I don't think it will, but it's just for the example)
> That's quite unclear for external people.
All versioning numbers are hard for some people to understand.
At least the current one has the advantage that Linux uses a similar
one so there are already some education materials out there.

> That's why I was wondering : why not use another, totally new numbering
> schema.
Because they're all less well-understood than our current one.
You wouldn't believe the confusion the YY.MM Ubuntu-ish pattern
seems to cause in new users.

> There's also another interest with this idea: if we change completly our
> numbering, we would not seem to be "late" against another software that
> is currently numbered 4.8 (i've been in Greece recently, for a talk in
> academic libraries. I saw that there is a big confusion here, and
> changing the numbering would also help I think).
Screw them.  If that's the only reason, let's skip to 5.8 for the
next release, or append ".not-a-LibLime-fake" to ours.  But do we
want to let them interfere with the real project in yet another way?

Regards,
--
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
http://koha-community.org supporter, web and LMS developer, statistician.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for Koha work http://www.software.coop/products/koha
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/



-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal