Hello If you want a librarian point of view, Koha 4 should have a major visible improvement for librarians and patrons, not only a change in infrastructure. And the main improvement we are waiting for is SolR. I don't even know what is DBIx::Class ;-) Mathieu Kyle Hall a écrit :

From what I've I've heard around the water cooler, we won't be switching to 4.x until there is some major change to the internal infrastructure of Koha ( like Solr support, or perhaps DBIx::Class support ).

I think if were to ditch the traditional versioning system, that maybe the Ubuntu year/month style would. So a major release this month would be version 13.04. I'm not endorsing it, it's just a possibility ; )

Kyle

http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com )

On Fri, Apr 5, 2013 at 3:40 AM, Paul Poulain <paul.poulain@biblibre.com <mailto:paul.poulain@biblibre.com>> wrote:

Hello koha-devel,

Throwing the question : after version 3.10, we're about to release 3.12, the next version is expected to be 3.14

My question is a small one : what does the "3." mean for us ? The 3.12 is really different from 3.0, that has been released 5 years ago. Remembering history, we switched from 1.x to 2.x when MARC support was added. We switched from 2.x to 3.x when zebra became our search engine.

What could/should we expect to decide to switch to 4.x ?

Another option I see could be to remove the "3." and name version 12.0, 12.1, 12.2, 14.0, 14.1,... (that would be fine for the current updatedatabase mechanism)

Thoughts ?

-- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper

_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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 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/

-- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr

I was not aware of that. I have no strong opinion on the matter in general, but I will say that with this style of versioning at least we wouldn't have to argue over what constitutes and justifies a major revision number change ; ) Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Fri, Apr 5, 2013 at 7:45 AM, MJ Ray <mjr@phonecoop.coop> wrote:

...

I think if were to ditch the traditional versioning system, that maybe

Kyle wrote: the

...

Ubuntu year/month style would. So a major release this month would be version 13.04. I'm not endorsing it, it's just a possibility ; )

If we go that way, please don't use the point as the divider because having soooo many skipped numbers is a source of confusion with Ubuntu and similar. At least Linux's "odd second numbers are for odd developers, even second numbers to keep on an even keel" has some explanation.

So please use 13-04 or 13/04 (or 2013-04 to make dating really clear?) for this possibility.

Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ _______________________________________________ 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/

On Fri, Apr 5, 2013 at 9:26 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:

As we have each 6 month a new major release, why not increment the major number on each of them ? And as we're about to release 3.12.0, my preference is slowly moving toward *removing* the 3. and saying each major release get it's major number. So 12.0, 12.1, 12.2,... then 14.0,...

I have no objection to dropping the 3. Kind Regards, Chris

Le 05/04/2013 15:26, Paul Poulain a écrit :

So 12.0, 12.1, 12.2,... then 14.0,... Another positive aspect of this option : 12.0 IS a number. 3.12.0 isn't ;-)

-- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper

On Fri, Apr 5, 2013 at 2:28 PM, Galen Charlton <gmc@esilibrary.com> wrote:

Consequently, I'd be happy if we kept the 3.x series going indefinitely, or if we bumped up the major version number when it felt right, or if we dropped the "3." and called the fall release 13.0 or 14.0.

Whatever gets decided, I *do* strongly feel that we collectively promise to stick to it for at least three years -- and *not* discuss it further.

In that case I vote for us to drop the 3 and go with the straight numbering. Nicole

On Fri, Apr 5, 2013 at 6:45 PM, Liz Rea <wizzyrea@gmail.com> wrote:

I too was looking forward to 3.14. I'm happy to change it after that.

:P

Yes, ok, it's a sentimental thing but... it's PI. COME ON.

So does that make for a potentially irrational release? Chris

At 03:37 PM 4/6/2013 +1300, Chris Cormack wrote:

Means we never need to worry about increasing the major number again, just keep adding digits. :) Chris Christopher Nighswonger <chris.nighswonger@gmail.com> wrote: On Fri, Apr 5, 2013 at 6:45 PM, Liz Rea <wizzyrea@gmail.com> wrote:

...

I too was looking forward to 3.14. I'm happy to change it after that. :P Yes, ok, it's a sentimental thing but... it's PI. COME ON.

So does that make for a potentially irrational release?

Well... there's nothing recurring with it, and nothing as vulgar as 22/7. Best - Paul

Le 05/04/2013 20:28, Galen Charlton a écrit :

I don't ask much of version number schemes. Really just two things: first, that they increase from version to version. Second, that we don't spend a great deal of time discussing them. :) OK, I propose to open a poll to have as many ppl opinion as possible. The most interested ppl being users/libraries themselves !

The poll would have the following options : * keep 3. "forever" * keep the 3. until a major functional change is made, like introducing a new search engine. The numbering change is decided by the Release Manager. * drop the 3. and use 14.0, 14.1, 14.2, 16.0, 16.1,... * adopt a numbering style with YYYY-MM (2013-11, 2014-05, 2014-11,...) QUESTION TO THIS LIST, before the poll: for the YYY-MM style, how to number the maintaince releases ? 2 weeks for voting, same vote method as for KohaCon : option ranked #1=4 points, option ranked #2=3pts, #3=2pts, #4=1pt, you can rank how many options as you want. -- Paul POULAIN - Associé-gérant Tel : (33) 4 91 81 35 08 http://www.biblibre.com Logiciels Libres pour les bibliothèques et les centres de documentation

At 12:15 AM 4/7/2013 +0200, Paul Poulain wrote: [snip]

The poll would have the following options : * keep 3. "forever" * keep the 3. until a major functional change is made, like introducing a new search engine. The numbering change is decided by the Release Manager. * drop the 3. and use 14.0, 14.1, 14.2, 16.0, 16.1,... * adopt a numbering style with YYYY-MM (2013-11, 2014-05, 2014-11,...) QUESTION TO THIS LIST, before the poll: for the YYY-MM style, how to number the maintaince releases ?

[Based on Ubuntu, clearly announced ahead of time, predictable for planning purposes in the long term] the year/months are on a six month cycle April/October: 12.04(LTS), 12.10, 13.04, 13.10, 14.04(LTS), 14.10 ... etc. [And for anyone wanting to be at the cutting edge there are beta and alphas leading up to the releases.] There are occasional "maintenance" releases in between, at least for the LTS releases -- e.g. at the moment, a year after 12.04 there is a 12.04.2(LTS) -- just a simple "dot digit" on the end, like Koha. But it's 12.04 plus security patches only (for the server edition) with no "enhancements." How many libraries using Koha really look at "new releases" every month or so? We are based on 3.8.5 which was state of the art when I put it into production six months ago. Koha is up to what? 3.8.11 plus 3.10.4 plus 3.12 beta plus 3.14 in the offing. And my system isn't even a "current stable release" any more ... Maybe the *numbering* of releases is less important than the *number* of releases? Would more time for testing and Q.A. lead to a more stable platform, say on a six monthly basis? Would it tempt more libraries to examine enhancements? ... and please, these are just questions, certainly not criticism. Best - Paul --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

Hello Maybe you will not agree with me, but here is my *personal *opinion about release rythm : 6 month between each "major" release seems quite a short delay. In France we have libraries using 3.10 (I think only my library for the moment), 3.8, probably 3.6, 3.2 (with a lot of local changes). In some monthes, we will have libraries using 3.12, 3.10, 3.8 etc For a library a 6 month rythm means updating 2 times Koha each year. Before and after each change, you need to test the new version, to train colleagues, to update documentation, to signal new bugs to your vendor if you have one... You can do that if you have a big team, and the help of a vendor. This is not the case of all libraries... It is also a problem for internationalization : translation teams need to maintain projects for 3 or 4 versions. With Pootle, it is not possible (how many languages with 100% strings translated for 3.10, 3.8 and 3.6 ???). Even with an other system it will be very difficult and will take a lot of time. Finally, in terms of development : with the current system, we work on enhancements approximatly 4 months (before feature freeze) for each version. So 8 month in a year. With a rythm of a year, we could work for example 9 months on enhancements, and 3 on bugfixes and translations. Regards, M. Saby Rennes 2 university Le 07/04/2013 02:43, Chris Cormack a écrit :

Paul <paul.a@aandc.org> wrote:

...

...

The poll would have the following options : * keep 3. "forever" * keep the 3. until a major functional change is made, like introducing a new search engine. The numbering change is decided by the Release Manager. * drop the 3. and use 14.0, 14.1, 14.2, 16.0, 16.1,... * adopt a numbering style with YYYY-MM (2013-11, 2014-05, 2014-11,...) QUESTION TO THIS LIST, before the poll: for the YYY-MM style, how to number the maintaince releases ? [Based on Ubuntu, clearly announced ahead of time, predictable for

At 12:15 AM 4/7/2013 +0200, Paul Poulain wrote: [snip] planning purposes in the long term] the year/months are on a six month cycle April/October: 12.04(LTS), 12.10, 13.04, 13.10, 14.04(LTS), 14.10 ... etc. [And for anyone wanting to be at the cutting edge there are beta and alphas leading up to the releases.]

There are occasional "maintenance" releases in between, at least for the LTS releases -- e.g. at the moment, a year after 12.04 there is a 12.04.2(LTS) -- just a simple "dot digit" on the end, like Koha. But it's 12.04 plus security patches only (for the server edition) with no "enhancements."

How many libraries using Koha really look at "new releases" every month or so? We are based on 3.8.5 which was state of the art when I put it into

production six months ago. Koha is up to what? 3.8.11 plus 3.10.4 plus 3.12 beta plus 3.14 in the offing. And my system isn't even a "current stable release" any more ...

Maybe the *numbering* of releases is less important than the *number* of releases? Would more time for testing and Q.A. lead to a more stable platform, say on a six monthly basis? Would it tempt more libraries to examine enhancements? ... and please, these are just questions, certainly not criticism. We only ever release enhancements every 6 months. The monthly releases are purely bug fixes. What you describe is what we do, 6 monthly feature releases. And yes 3.8.11 is 3.8.5 plus 6 months of bugfixes. As 3.8.5 was 3.8.0 plus 5 months of bug fix releases.

Maybe you have just misunderstood the current system.

Chris

...

Best - Paul

--- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

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

-- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr

Hi Mathieu, you are right in that updating every half year is a lot of work, but the good thing is, that you don't have to. We have libraries that are still on 3.6.x now and we will probably update them directly to 3.12 sometime this year. The positive side on half year feature releases is that you can get to use your sponsored enhancements quicker if you want to. Libraries don't have to wait a full year worst case or even longer, if for whatever reason their developments can't go into the very next release. As it stands Koha changes a lot in short amounts of time. Our release notes show that quite well and I think we should keep our cycle. Translations are always a bit of a pain to do, that won't change with different tools or different kinds of releases in my opinion. But the bugfix releases don't introduce a lot of new strings. It's the big releases that do and I think we wouldn't reduce work with longer release cycles. Katrin Am 07.04.2013 10:27, schrieb Mathieu Saby:

Hello Maybe you will not agree with me, but here is my *personal *opinion about release rythm : 6 month between each "major" release seems quite a short delay. In France we have libraries using 3.10 (I think only my library for the moment), 3.8, probably 3.6, 3.2 (with a lot of local changes). In some monthes, we will have libraries using 3.12, 3.10, 3.8 etc

For a library a 6 month rythm means updating 2 times Koha each year. Before and after each change, you need to test the new version, to train colleagues, to update documentation, to signal new bugs to your vendor if you have one... You can do that if you have a big team, and the help of a vendor. This is not the case of all libraries... It is also a problem for internationalization : translation teams need to maintain projects for 3 or 4 versions. With Pootle, it is not possible (how many languages with 100% strings translated for 3.10, 3.8 and 3.6 ???). Even with an other system it will be very difficult and will take a lot of time. Finally, in terms of development : with the current system, we work on enhancements approximatly 4 months (before feature freeze) for each version. So 8 month in a year. With a rythm of a year, we could work for example 9 months on enhancements, and 3 on bugfixes and translations.

Regards, M. Saby Rennes 2 university

I think this is a worthwhile discussion to have, and I'm actually in no hurry (yet) to cut it off. I think there are still aspects which need to be considered. Version numbering is important to different groups for different reasons. For developers, we need version numbering to keep track of where we are in the release cycle and to help us make judgements about how to manage and maintain previous releases. For users the version number gives them an indication about how important it is to upgrade.

But please do not jump from 3 to 14 !

When considering users, I think this is an important consideration. Jumping from 3 to 14 would be really confusing to users, and create expectations about what that version number means. Did we jump 11 version numbers because 3.14 is 11 version numbers better than 3.12? Did we jump 11 version numbers because a pseudo-Koha project has practiced version number inflation? No matter how well we communicate our reasons for switching numbering systems these questions are going to come up. Are we okay with that? I agree with those who worry that incrementing full version numbers like we did point releases before is going to make it more difficult for users to know how important it is to upgrade. As developers we know how much work goes into making 3.10 into 3.12, but users have to weigh a lot of factors when deciding whether and when to upgrade. Self-supporting libraries in particular may not have the resources to upgrade for every version. Will a new numbering scheme make this more difficult for them? All that said, I think it is problematic that we don't have a plan, under the current numbering scheme, to move from 3.x to 4.x. Just to muddy the waters more: What if we came up with a goal (or goals) to set to trigger the flip from 3 to 4, and then implemented the new version scheme from there? That would give the users the satisfaction of seeing a version jump, and give us some lead time to "sell" the new numbering scheme. With apologies to those who want this to be over, -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

Thank you for Katrin & Chris for your answers ( I also read some comments on irc...) You convinced me, 1 year release would be a bad idea ;-) Mathieu Le 07/04/2013 10:48, Katrin Fischer a écrit :

Hi Mathieu,

you are right in that updating every half year is a lot of work, but the good thing is, that you don't have to. We have libraries that are still on 3.6.x now and we will probably update them directly to 3.12 sometime this year.

The positive side on half year feature releases is that you can get to use your sponsored enhancements quicker if you want to. Libraries don't have to wait a full year worst case or even longer, if for whatever reason their developments can't go into the very next release. As it stands Koha changes a lot in short amounts of time. Our release notes show that quite well and I think we should keep our cycle.

Translations are always a bit of a pain to do, that won't change with different tools or different kinds of releases in my opinion. But the bugfix releases don't introduce a lot of new strings. It's the big releases that do and I think we wouldn't reduce work with longer release cycles.

Katrin

Am 07.04.2013 10:27, schrieb Mathieu Saby:

...

Hello Maybe you will not agree with me, but here is my *personal *opinion about release rythm : 6 month between each "major" release seems quite a short delay. In France we have libraries using 3.10 (I think only my library for the moment), 3.8, probably 3.6, 3.2 (with a lot of local changes). In some monthes, we will have libraries using 3.12, 3.10, 3.8 etc

For a library a 6 month rythm means updating 2 times Koha each year. Before and after each change, you need to test the new version, to train colleagues, to update documentation, to signal new bugs to your vendor if you have one... You can do that if you have a big team, and the help of a vendor. This is not the case of all libraries... It is also a problem for internationalization : translation teams need to maintain projects for 3 or 4 versions. With Pootle, it is not possible (how many languages with 100% strings translated for 3.10, 3.8 and 3.6 ???). Even with an other system it will be very difficult and will take a lot of time. Finally, in terms of development : with the current system, we work on enhancements approximatly 4 months (before feature freeze) for each version. So 8 month in a year. With a rythm of a year, we could work for example 9 months on enhancements, and 3 on bugfixes and translations.

Regards, M. Saby Rennes 2 university

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

-- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr

Yes, lots of patches, and - it would be difficult to find a RM for 1 year, - libraries would not be happy if they have to wait 1 year to see their sponsored devs pushed in master, - the update from 3.0 to 3.2 (2 years...) seems to be a very very bad memory for lot of people (I think at that time I had never heard of Koha ;-) ) Mathieu Chris Cormack a écrit :

On 8 April 2013 10:43, Mathieu Saby <mathieu.saby@univ-rennes2.fr> wrote:

...

Thank you for Katrin & Chris for your answers ( I also read some comments on irc...) You convinced me, 1 year release would be a bad idea ;-)

Perhaps you read the stats for 3.12.0 on IRC?

For other people it was 771 patches from 59 people in less than 5 months .. its now one day later and it is now

796 from 60 people, so yeah Koha changes rapidly :)

Chris

-- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr

Galen Charlton schreef op vr 05-04-2013 om 11:28 [-0700]:

Really just two things: first, that they increase from version to version.

I reserve the right to get grumpy if they don't map cleanly into the debian versioning scheme.

Second, that we don't spend a great deal of time discussing them. :)

I think that ship has sailed, just looking ahead in the thread :) We could reserve 4.x for the Java port... -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D