Version numbering, starting a discussion

classic Classic list List threaded Threaded
21 messages Options
Reply | Threaded
Open this post in threaded view
|

Version numbering, starting a discussion

paul POULAIN-3
Hello,

There are 2 questions in this mail:
=== DB update numbering ===
The bug 7167 will probably pushed in a few days, and it's a new way to
handle updatedatabase. They will be non-linear, meaning update 1 can be
applied after update 2, and before update 3.
The previous numbering pattern, made from 4 parts (3.06.00.001 for
example) was made to handle release version + DB version.
The 1st update for version 3.8.3 would be called 3.08.03.001 for example.

With the new scheme, there's no need to have a so complex numbering
system. We could just number our databases update 1, 2, 3, ...

What do you think of this idea ? Why should we keep the previous
numbering scheme ? Any other suggestion ?

=== Koha version numbering ===
This second topic is a harder one. So please, don't jump on this and
forget the 1st one.
I was wondering why/if we should continue with our 3.6 / 3.8 / 4.0 / ...
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.

That's why I was wondering : why not use another, totally new numbering
schema.
The "koha april 2012" could be called 2012.A, or 12.A, or 12.1. The
"Koha October 2012" could be called 2012.B, or 12.B, or 12.2 (or any
other scheme, I'm open to any proposal, including not changing, I just
want to share the idea. - we should just avoid Ubuntu numbering patter:
12.4 / 12.10 would be a bad idea, as Ubuntu is released in april and
october, like Koha. So it may be confusing -)
What we need is a number for each monthly maintainance release. But for
the rest, what about changing everything in our numbering method ?

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

Let's start the discussion, but please, on both topics, that are related
but different: we could change #1 and not #2 !
--
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08
_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

Chris Cormack-6
On 1 December 2011 21:11, Paul Poulain <[hidden email]> wrote:

> Hello,
>
> There are 2 questions in this mail:
> === DB update numbering ===
> The bug 7167 will probably pushed in a few days, and it's a new way to
> handle updatedatabase. They will be non-linear, meaning update 1 can be
> applied after update 2, and before update 3.
> The previous numbering pattern, made from 4 parts (3.06.00.001 for
> example) was made to handle release version + DB version.
> The 1st update for version 3.8.3 would be called 3.08.03.001 for example.
>
> With the new scheme, there's no need to have a so complex numbering
> system. We could just number our databases update 1, 2, 3, ...
>
> What do you think of this idea ? Why should we keep the previous
> numbering scheme ? Any other suggestion ?
>
> === Koha version numbering ===
> This second topic is a harder one. So please, don't jump on this and
> forget the 1st one.
> I was wondering why/if we should continue with our 3.6 / 3.8 / 4.0 / ...
> 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.
>
> That's why I was wondering : why not use another, totally new numbering
> schema.
> The "koha april 2012" could be called 2012.A, or 12.A, or 12.1. The
> "Koha October 2012" could be called 2012.B, or 12.B, or 12.2 (or any
> other scheme, I'm open to any proposal, including not changing, I just
> want to share the idea. - we should just avoid Ubuntu numbering patter:
> 12.4 / 12.10 would be a bad idea, as Ubuntu is released in april and
> october, like Koha. So it may be confusing -)
> What we need is a number for each monthly maintainance release. But for
> the rest, what about changing everything in our numbering method ?
>
> 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).
>
> Let's start the discussion, but please, on both topics, that are related
> but different: we could change #1 and not #2 !
> --

Remembering that we also do maintenance releases, what would they be
2012.A.1 2012.A.2 ?

I think the confusion comes in when we talk about 3.8 .. we never do
releases like that, its 3.8.0, 3.8.1 etc. Having the third number is
very handy, and will be very useful when we get Koha into debian which
we are working on.

As for the db versions, I have no opinion on that, so my vote is
abstain for 1, and -1 for 2

Chris
_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

MJ Ray-2
In reply to this post by paul POULAIN-3
Paul Poulain <[hidden email]>
> === 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
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:
Paul Poulain <[hidden email]>
> === 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



--
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
[hidden email]
Twitter: @sekjal

_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

Owen Leonard-4
In reply to this post by MJ Ray-2
> 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?

I strongly agree with this.

  -- Owen

--
Web Developer
Athens County Public Libraries
http://www.myacpl.org
_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

Fischer, Katrin
In reply to this post by Ian Walls
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: [hidden email] [mailto:[hidden email]] On Behalf Of Ian Walls
Sent: Thursday, December 01, 2011 1:46 PM
To: MJ Ray
Cc: [hidden email]
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 <[hidden email]> wrote:
Paul Poulain <[hidden email]>
> === 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
[hidden email]
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
[hidden email]
Twitter: @sekjal
_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

Jared Camins-Esakov-2
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Ian Walls
Sent: Thursday, December 01, 2011 1:46 PM
To: MJ Ray
Cc: [hidden email]
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 <[hidden email]> wrote:
Paul Poulain <[hidden email]>
> === 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
[hidden email]
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 # <a href="tel:%28888%29%20900-8944" value="+18889008944">(888) 900-8944
http://bywatersolutions.com
[hidden email]
Twitter: @sekjal
_______________________________________________
Koha-devel mailing list
[hidden email]
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


_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

Ian Walls
In reply to this post by Fischer, Katrin
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Ian Walls
Sent: Thursday, December 01, 2011 1:46 PM
To: MJ Ray
Cc: [hidden email]
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 <[hidden email]> wrote:
Paul Poulain <[hidden email]>
> === 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
[hidden email]
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 # <a href="tel:%28888%29%20900-8944" value="+18889008944">(888) 900-8944
http://bywatersolutions.com
[hidden email]
Twitter: @sekjal
_______________________________________________
Koha-devel mailing list
[hidden email]
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
[hidden email]
Twitter: @sekjal

_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

Chris Nighswonger
2011/12/1 Ian Walls <[hidden email]>:
> About your first suggestion (the one you didn't want to get buried in the
> discussion of part 2):
>

<snip>

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

DB version really becomes meaningless for master/dev use once we allow
non-linear and selective application of DB related changes. The only
time everyone is likely to be at a common DB version will be at
major/maintenance release times. And even then, if someone has opted
out of certain DB changes, they may never be "in sync" with everyone
else.

This leads me to think that the use of hashes is the best option. As
Ian mentions, this is common to version control systems which is
really what we are talking about here: a DB version control system.

/me wonders if we are not re-inventing the wheel here... there's only
so many ways to make it round, you know.

Kind Regards,
Chris
_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

Robin Sheat-2
In reply to this post by Jared Camins-Esakov-2
Op 04-12-11 15:04, Mason James schreef:
>>> 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.

Been done, kinda. I have Android devices running Froyo (an Americanism I
guess), Honeycomb (what I think the rest of us call hokey-pokey) and Ice
Cream Sandwich (an interesting idea.) Not that I'm averse to it :) I
think I prefer it to names such as Onanistic Ocelot[0] ;)

> we could also consider switching to the Debian style?, i have found it quite easy to understand.
> would it work well for Koha?

fwiw (and this won't affect anything to do with Koha numbering), I've
been numbering the Debian packages in the Debian style, but as the
package detail is in upstream we never get away from '-1' (which is OK)
e.g. 3.06.01 is 3.6.1-1. The master builds are along the lines of
3.7-1~git<timestamp>.<git-hash> or something like that.

Should I ever need to push a patch in the packaging itself, it would
become 3.6.1-2. This matters in debian-land because the source is base
on the part before the '-', the stuff after that is debian-release-specific.

[0] not the real name.

Robin.


_______________________________________________
Koha-devel mailing list
[hidden email]
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/

signature.asc (270 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

MJ Ray-2
In reply to this post by paul POULAIN-3
Mason James <[hidden email]>
> we could also consider switching to the Debian style?, i have found it quite easy to understand.
> would it work well for Koha?
>
>
> the Debian project uses both an internal 'linux-kernal' style numbering system (like Koha does already) and people-friendly nick-names too... :)

Debian's x.y.z number is not quite linux-style: there have been full
(non-development) x.1 release versions.

I'm not against the idea but a difficulty I have with Debian's
nick-names is that (except for sid) there seems little meaning or
relationship or progression to them, so remembering that lenny is 5.0
and squeeze is 6.0 is not straightforward for me.

Hope that informs,
--
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
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

Mirko Tietgen
Mason James schrieb am 05.12.2011 09:10:26
>
> both android and ubuntu choose their release names in
> alphabetical sequence, (like a,b,c,d) as a workaround to your
> problem
>
> ...we could do that too?, (eg: brie, cheddar, durrus)
>

Please don't do this. There are so many nice things in the world and
you want to name it after rotten milk? Nooooo. Think of the lactose
intolerant, vegans and people with irrational aversions (like me).
_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

BWS Johnson-2

Salvete!

>>  how about vegetables? (asparagus, broccoli, carrot, etc...)
>

    If we're going to be this silly, I'd go with Cait's sweets idea modified for the appropriate nationality of the KohaCon host for the year the release is out. 

>
> my favorite (other than any food category) is important librarians, (Avram,
> Cutter, Dewey, etc...)
>

    Screw Dewey, he took students' eye colour and waist size.

Cheers,
Brooke
_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

Owen Leonard-4
In reply to this post by Owen Leonard-4
On Sat, Dec 3, 2011 at 7:34 PM, Mason James <[hidden email]> wrote:

>
> On 2011-12-2, at 2:31 AM, Owen Leonard wrote:
>
>>> 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?
>>
>> I strongly agree with this.
>
> yeah, i'm kinda OK with this too... (a bump to 5.8 for the next Koha release)

Okay, just to be clear, I was strongly agreeing with the "screw them"
part. I interpreted the 5.8 comment as sarcasm.

 -- Owen


--
Web Developer
Athens County Public Libraries
http://www.myacpl.org
_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

Jared Camins-Esakov-2
In reply to this post by BWS Johnson-2
It seems to me that my input is called for here.
 
>     If we're going to be this silly, I'd go with Cait's sweets idea modified for the appropriate nationality of the KohaCon host for the year the release is out.
>>
>> my favorite (other than any food category) is important librarians, (Avram,
>> Cutter, Dewey, etc...)
>>
>
>     Screw Dewey, he took students' eye colour and waist size.


yeah, i like sweets the most too, it's a fun theme :)

Agreed. And we must have a Koha x.y.6 Frambois Fudge.

dead librarians are a bit obscure and boring (no offense people)

I'm not included in that category. Just sayin'.

Regards,
Jared 

--
Jared Camins-Esakov
Bibliographer, C & P Bibliography Services, LLC
(phone) +1 (917) 727-3445


_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

Mirko Tietgen
In reply to this post by Mirko Tietgen
Mason James schrieb am 05.12.2011 13:51:05

>
> ok, so make a better suggestion.  
>
> how about vegetables? (asparagus, broccoli, carrot, etc...)
>

puredyne[1] seems to be using something in that direction with names
like "leek and potato" and "carrot and coriander".

Personally, I like the "sweets" approach that was already mentioned
in this thread. Koha is much sweeter than, let's say, a lime. On the
other hand, I would also like "fruit" as a theme. I would love
"Omniscient orange"!

Cheers,

Mirko


[1] http://puredyne.org/
_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

Chris Nighswonger
2011/12/5 Mason James <[hidden email]>:
>
> theres a very impressive list of them on wikipedia
> http://en.wikipedia.org/wiki/List_of_culinary_fruits

We could also use astronomical names of stars, constellations, etc.

Kind Regards,
Chris
_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

Axel Bojer
Den 05. des. 2011 22:05, skrev Chris Nighswonger:
> 2011/12/5 Mason James <[hidden email]>:
>>
>> theres a very impressive list of them on wikipedia
>> http://en.wikipedia.org/wiki/List_of_culinary_fruits
>
> We could also use astronomical names of stars, constellations, etc.

If by names: Why not famous book titles?
Something related to libraries ...
Makes it easier to remember at least, and more relevant :-)

-A.
_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion

Ramon Andiñach
In reply to this post by Owen Leonard-4

On 05/12/2011, at 10:30 , Owen Leonard wrote:

> On Sat, Dec 3, 2011 at 7:34 PM, Mason James <[hidden email]> wrote:
>>
>> On 2011-12-2, at 2:31 AM, Owen Leonard wrote:
>>
>>>> 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?
>>>
>>> I strongly agree with this.
>>
>> yeah, i'm kinda OK with this too... (a bump to 5.8 for the next Koha release)
>
> Okay, just to be clear, I was strongly agreeing with the "screw them"
> part. I interpreted the 5.8 comment as sarcasm.
>
> -- Owen

A counter thought.
Some time back a small but useful browser called Netscape skipped numbers to bring its numbers in line with IE.
I always felt that this was pandering to IE, and letting the competition set the schedule.

That said, anything but Mozilla's current numbering scheme/philosophy! Even Ubuntu's is more intelligible than that.

As for the naming idea. Two ideas:
1. Words with roughly similar meanings to koha. (I suspect there's not enough, but haven't really looked into it)
2. Other famous "gifts" (other than koha!).

-ramon.
_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion - LTS

Partha Mukhopadhyay

What about LTS (Long Term Support) release in every six months?

 

----------------------------------------------------

Dr. Parthasarathi Mukhopadhyay

Lecturer (Sr. Scale)

Department of Library and Information Science

The University of Burdwan (WB)

------------------------------------------


At 5 Dec 2011 23:19:26 +0100 (CET) from "Ramon Andiñach" <[hidden email]>:


On 05/12/2011, at 10:30 , Owen Leonard wrote:

> On Sat, Dec 3, 2011 at 7:34 PM, Mason James <[hidden email]> wrote:


>>
>> On 2011-12-2, at 2:31 AM, Owen Leonard wrote:
>>
>>>> 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?
>>>
>>> I strongly agree with this.
>>
>> yeah, i'm kinda OK with this too... (a bump to 5.8 for the next Koha release)
>
> Okay, just to be clear, I was strongly agreeing with the "screw them"
> part. I interpreted the 5.8 comment as sarcasm.
>
> -- Owen

A counter thought.

Some time back a small but useful browser called Netscape skipped numbers to bring its numbers in line with IE.
I always felt that this was pandering to IE, and letting the competition set the schedule.

That said, anything but Mozilla's current numbering scheme/philosophy! Even Ubuntu's is more intelligible than that.

As for the naming idea. Two ideas:
1. Words with roughly similar meanings to koha. (I suspect there's not enough, but haven't really looked into it)
2. Other famous "gifts" (other than koha!).

-ramon.
_______________________________________________
Koha-devel mailing list
Koha-devel@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/


_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Version numbering, starting a discussion - LTS

Mirko Tietgen
If this is an offer to sponsor the maintenance of a LTS release
(with money or labour), such a version once in a while could be
interesting to some. There might be support firms that can offer
such a paid service. You can find a list on
http://www.koha-community.org/

I don't see why every big Koha release (coming every six months)
should be LTS though.

Best,

Mirko




Partha Mukhopadhyay schrieb am 07.12.2011 12:44:44

> What about LTS (Long Term Support) release in every six months?
>
> ----------------------------------------------------
>
> Dr. Parthasarathi Mukhopadhyay
>
> Lecturer (Sr. Scale)
>
> Department of Library and Information Science
>
> The University of Burdwan (WB)
>
> ------------------------------------------
>
_______________________________________________
Koha-devel mailing list
[hidden email]
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/