I think you have some good ideas here. It seems to me that support for each release drops off rather dramatically. Our oldest supported release is currently 3.8 which was first released about 1 year ago!

Right now I believe a release is only supported as long as we have a maintainer willing to do the work.

Assuming an LTS release has 2 years of support, let's look at the following scenario:
2013.04 ( LTS ) - Supported for 2 years, until the release of version 2015.04
2013.10 - Supported until the release of 2014.10
2014.04 - Supported until the release of 2015.04
2014.10 - Supported until the release of 2015.10, support for 2013.10 ends
2015.04 ( LTS ) - Supported until 2017.04, support for 2013.04 (LTS ) and 2014.04 ends.

So with this system, we would need 3 release maintainers at any given time, right? 1 for LTS and 2 for non-LTS releases.

Here is the same scenario with Paul's prefered numbering system:
12.x ( LTS ) - Supported for 2 years, until the release of version 16.x
13.x - Supported until the release of 15.x
14.x - Supported until the release of 16.x
15.x - Supported until the release of 17.x, support for 13.x ends
16.x ( LTS ) - Supported until 20.x, support for 12.x (LTS) and 14.x ends.

I think Paul's proposal is certainly more grokable than my Ubuntu style as well. To get the support sunset for an LTS release, add 4 to it. To get the support sunset for a non-LTS release, just add 2.

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

My $0.2 and YMMV,

Best regards and thanks for all the hard work,
Paul
_______________________________________________
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/