[Koha-devel] LTS support (branching the "Koha numbering" thread)

[Tomas Cohen Arazi]

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

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+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20130405/b7b0c508/attachment-0001.html>