[Koha-devel] Version numbering, starting a discussion

Thu Dec 1 16:31:18 CET 2011

Katrin failed to mention her excellent counter-proposal to Ian's suggestion
of cheese as a theme: cookies and other sweets as the theme. Koha 3.8
Curried coconut oatmeal chocolate chip cookies, etc.

Regards,
Jared

On Thu, Dec 1, 2011 at 10:22 AM, Fischer, Katrin
<Katrin.Fischer at bsz-bw.de>wrote:

> 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
> _______________________________________________
> 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/
>

-- 
Jared Camins-Esakov
Bibliographer, C & P Bibliography Services, LLC
(phone) +1 (917) 727-3445
(e-mail) jcamins at cpbibliography.com
(web) http://www.cpbibliography.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20111201/0933bf5a/attachment-0001.htm>