[Koha-devel] Version numbering, starting a discussion

[Ian Walls]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20111201/49e08504/attachment.htm>