[Koha-devel] Version numbering, starting a discussion

Thu Dec 1 16:38:24 CET 2011

Paul,

About your first suggestion (the one you didn't want to get buried in the
discussion of part 2):

It would be feasible to employ a new numbers system just for DB revs (not
for releases).  DB rev is only really used in master, so the third number
(maintenance release) is always "00".

What we really need is a multi-headed path through DB revs.  We need to be
able to trace the DB revision history for both master and stable releases.
I'd really like to see an easy way to convert back and forth, so if you're
on master, and want to change to stable, you don't have to move the earth.

DB revs need to maintain a sequence, as sometimes order of application is
important.  But if two completely orthogonal things are applied out of
sequence, it really doesn't matter.  Oh, wait, this is just like in Git!

That would lead me back to using a Hash to keep track of the current
default DB state, but as it's not just structure, but also data, that gets
more complex than possibility really allows.

-Ian

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

-- 
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/864f939d/attachment.htm>