[Koha-devel] Koha numbering

[Kyle Hall]

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 at 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 at lists.koha-**community.org<Koha-devel at lists.koha-community.org>
> http://lists.koha-community.**org/cgi-bin/mailman/listinfo/**koha-devel<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/ <http://bugs.koha-community.org/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20130405/5e652cff/attachment.html>