Maybe this could go into a different thread? I think is off-topic On Fri, Apr 5, 2013 at 10:32 AM, Paul <paul.a@aandc.org> wrote:

At 07:34 AM 4/5/2013 -0400, Kyle Hall wrote:

...

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

I would very much like to see something along the "Ubuntu style" as *production* is very different from development and product improvement and/or security issues (which is great/marvelous, to be encouraged, the life and soul of an open-source project, etc)

Many (most?) production environments are based upon a two-year cycle with security upgrades; this opinion based on the last twenty years of IT proliferation out of my fifty years in IT. Enhancements come down to a question of "is it really helpful in our environment?" and "what are the risks/costs of modifying a working system?" (Some of us are more/less blessed with a permanent sandbox capability and the time/resources to use it beneficially for our commercial/charitable goals. But this should not be relied upon.)

A two year "LTS" cycle, with a further two years "support", plus one more year of "not dropping off the edge of the world" works extremely well as a policy principle, which I feel must be based upon a principle of "if it ain't broke, don't fix it." (Ubuntu is slowly getting there - it's now nearly trivial to limit apt-get upgrade to security issues only, and consider product enhancements at a totally separate level. Could Koha do the same with the "package" option? One of the reasons that I use tarballs is the granularity of looking through the release notes for security issues.)

I belive LTS could be a good thing for Koha. The main problem is that the effort needs to be done by someone. The current way of handling this ("version XX will be deprecated unless someone steps in as release maintainer") is a good approach in this scenario. If an institution (or group of them) is not ready for a major version jump, they should sponsor the maintenance of their current version. We plan to use 3.12 as soon as it gets stabilized until something really better arises. Version numbering *might* be related to LTS in the way we currentl name packages and things that need to be done to retain a certain version from a major upgrade. I'd go for the naming schema is used for virtualbox (for example): koha-common-3.10 koha-common-3.12 and so on. Regards To+