<div dir="ltr">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!<div>
<br></div><div style>Right now I believe a release is only supported as long as we have a maintainer willing to do the work.</div><div style><br></div><div style>Assuming an LTS release has 2 years of support, let's look at the following scenario:<br>
</div><div style>2013.04 ( LTS ) - Supported for 2 years, until the release of version 2015.04</div><div style>2013.10 - Supported until the release of 2014.10</div><div style>2014.04 - Supported until the release of 2015.04</div>
<div style>2014.10 - Supported until the release of 2015.10, support for 2013.10 ends</div><div style>2015.04 ( LTS ) - Supported until 2017.04, support for 2013.04 (LTS ) and 2014.04 ends.</div><div style><br></div><div style>
So with this system, we would need 3 release maintainers at any given time, right? 1 for LTS and 2 for non-LTS releases.</div><div style><br></div><div style>Here is the same scenario with Paul's prefered numbering system:</div>
<div style><div>12.x ( LTS ) - Supported for 2 years, until the release of version 16.x</div><div>13.x - Supported until the release of 15.x</div><div>14.x - Supported until the release of 16.x</div><div>15.x - Supported until the release of 17.x, support for 13.x ends</div>
<div>16.x ( LTS ) - Supported until 20.x, support for 12.x (LTS) and 14.x ends.</div><div><br></div><div style>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.</div>
<div style><br></div><div style>Kyle</div><div><br></div></div></div><div class="gmail_extra"><br clear="all"><div><a href="http://www.kylehall.info" target="_blank">http://www.kylehall.info</a><br>ByWater Solutions ( <a href="http://bywatersolutions.com" target="_blank">http://bywatersolutions.com</a> )<br>
Meadville Public Library ( <a href="http://www.meadvillelibrary.org" target="_blank">http://www.meadvillelibrary.org</a> )<br>Crawford County Federated Library System ( <a href="http://www.ccfls.org" target="_blank">http://www.ccfls.org</a> )<br>
Mill Run Technology Solutions ( <a href="http://millruntech.com" target="_blank">http://millruntech.com</a> )<br></div>
<br><br><div class="gmail_quote">On Fri, Apr 5, 2013 at 9:32 AM, Paul <span dir="ltr"><<a href="mailto:paul.a@aandc.org" target="_blank">paul.a@aandc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">At 07:34 AM 4/5/2013 -0400, Kyle Hall wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
>From what I've I've heard around the water cooler, we won't be switching to<br>
4.x until there is some major change to the internal infrastructure of Koha<br>
( like Solr support, or perhaps DBIx::Class support ).<br>
<br></div><div class="im">
I think if were to ditch the traditional versioning system, that maybe the<br>
Ubuntu year/month style would. So a major release this month would be<br>
version 13.04. I'm not endorsing it, it's just a possibility ; )<br>
</div></blockquote>
<br>
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)<br>

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

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

<br>
My $0.2 and YMMV,<br>
<br>
Best regards and thanks for all the hard work,<br>
Paul <br><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
Koha-devel mailing list<br>
<a href="mailto:Koha-devel@lists.koha-community.org" target="_blank">Koha-devel@lists.koha-<u></u>community.org</a><br>
<a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" target="_blank">http://lists.koha-community.<u></u>org/cgi-bin/mailman/listinfo/<u></u>koha-devel</a><br>
website : <a href="http://www.koha-community.org/" target="_blank">http://www.koha-community.org/</a><br>
git : <a href="http://git.koha-community.org/" target="_blank">http://git.koha-community.org/</a><br>
bugs : <a href="http://bugs.koha-community.org/" target="_blank">http://bugs.koha-community.<u></u>org/</a><br>
</div></div></blockquote></div><br></div>