Re: [Koha-devel] Release cycle [was: Ubuntu support]
At 03:35 PM 7/18/2012 -0300, Tomas Cohen Arazi wrote:
I've been struggling with
I'd be happy to try and assist with this documentation. I struggled with 3.8 on our sandbox (maybe less than Tomas, as it's a i386) and will probably struggle again if/when I put 3.8.x onto a production 686 server. For the record, the Ubuntu LTS release cycle is not quite "pure" 2-year as Tomas suggests below. New LTSs are released every two years, but end-of-life is after five years (e.g. current 12.04 LTS is valid until April 2017.) The 10.04 server (Lucid) is valid until April 2015, and the older 8.04 Heron server is still valid until April 2013 and could probably be dropped (together with 10.10 (Maverick) which was never an LTS.) This Ubuntu cycle has the great advantage of being able to "jump" one LTS, and still have a year of "old" validity before deploying "new". Is there any chance of using a similar "release cycle" as far as LTS is concerned for Koha? I've been trying to follow the emails on this subject, but have problems wrapping my greycells around gits and masters, releases and sub-releases, bugs on a scale from trivial to blocker, enhancements announced as bugs, etc. I realize, of course, that all of you who put in tireless effort on Koha (and I certainly respect and thank you for it), have developed a release cycle that suits your input as efficiently as possible. But also, I have to admit that I'm more used to LTS, stable and "beta" (for whatever values of "at your own risk" they might take) with enhancements clearly differentiated from security updates. Having followed the Koha Users list as far as 3.8 is concerned (and I'm not really suggesting that it's not stable) I'm taking a lot more time than I did with 3.6 to consider putting it into production. And I haven't even looked at 3.6.2-7 because 3.8 was available by the time I got our people trained on 3.6.1 In our production environment (two fairly big servers), the first consideration when looking at updates is stability, whether it's for Apache, SendMail, SQL, OpenOffice, whatever. ROI (cost versus enhancement) comes later. I'd be interested to know, from your (developers') point of view, which version of Koha you consider closest to "Long Term Stable"? Best - Paul At 03:35 PM 7/18/2012 -0300, Tomas Cohen Arazi wrote:
I've been struggling with
$ dselect --set-selections install_misc/ubuntu.packages $ dselect install
pulling i386 packages and trying to break my poor amd64 12.04 PVM, and started to dig on problems related to Ubuntu support and docs problems. The most bugs reported have to do with docs being outdated. And whether a patch should be applied or not depends on this question: What Ubuntu versions should we support?
My vote is for the current LTS revisions only (lucid and precise, the first being outdated for master i guess, not sure). Their 2-year release cycle seems to be enough for having a fair recent version of the required libs. So, this files might need being updated/deleted and new ones created:
INSTALL.ubuntu INSTALL.ubuntu.lucid ubuntu_maverick.packages (delete or at least rename!) ubuntu.packages ubuntu-pkg-check.sh
I propose:
INSTALL.ubuntu.lucid INSTALL.ubuntu.precise install_misc/ubuntu_lucid.packages install_misc/ubuntu_precise.packages
The idea is avoiding confusion. I'd volunteer to help on this task. Bugs related to this:
- http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7764 - INSTALL.ubuntu needs updating - http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7759 - Use Koha-Contrib-Tamil to update Zebra data in background (needs to be documented in the INSTALL.* files) - http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7858 - Missing packages from install_misc/ubuntu.packages - http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8192 - Update libraries and Missing library in install_misc/ubuntu.packages - http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5217 - INSTALL.ubuntu Packages/CPAN notes out of date for Ubuntu 10.04 LTS (Lucid)
Regards To+ _______________________________________________
On 19 July 2012 08:06, Paul <paul.a@aandc.org> wrote:
At 03:35 PM 7/18/2012 -0300, Tomas Cohen Arazi wrote:
I've been struggling with
I'd be happy to try and assist with this documentation. I struggled with 3.8 on our sandbox (maybe less than Tomas, as it's a i386) and will probably struggle again if/when I put 3.8.x onto a production 686 server.
For the record, the Ubuntu LTS release cycle is not quite "pure" 2-year as Tomas suggests below. New LTSs are released every two years, but end-of-life is after five years (e.g. current 12.04 LTS is valid until April 2017.) The 10.04 server (Lucid) is valid until April 2015, and the older 8.04 Heron server is still valid until April 2013 and could probably be dropped (together with 10.10 (Maverick) which was never an LTS.)
This Ubuntu cycle has the great advantage of being able to "jump" one LTS, and still have a year of "old" validity before deploying "new".
Is there any chance of using a similar "release cycle" as far as LTS is concerned for Koha? I've been trying to follow the emails on this subject, but have problems wrapping my greycells around gits and masters, releases and sub-releases, bugs on a scale from trivial to blocker, enhancements announced as bugs, etc.
I realize, of course, that all of you who put in tireless effort on Koha (and I certainly respect and thank you for it), have developed a release cycle that suits your input as efficiently as possible. But also, I have to admit that I'm more used to LTS, stable and "beta" (for whatever values of "at your own risk" they might take) with enhancements clearly differentiated from security updates. Having followed the Koha Users list as far as 3.8 is concerned (and I'm not really suggesting that it's not stable) I'm taking a lot more time than I did with 3.6 to consider putting it into production. And I haven't even looked at 3.6.2-7 because 3.8 was available by the time I got our people trained on 3.6.1
As with everything with Koha, it's doable. However you need to find someone who is willing to maintain that LTS release for it, which is almost a full time job. And 3.6.7 is the current most rocksolid release. I would definitely not be on 3.6.1 security fixes were pushed for the 3.6.x branch. This is where the packages win .. again. So in short yes, an LTS release is possible, do you want to maintain it? (Or if not, can you convince someone else to) :) Chris
Greetings, [snip]
New LTSs are released every two years, but end-of-life is after five years (e.g. current 12.04 LTS is valid until April 2017.) The 10.04 server (Lucid) is valid until April 2015, and the older 8.04 Heron server is still valid until April 2013 and could probably be dropped (together with 10.10 (Maverick) which was never an LTS.)
This Ubuntu cycle has the great advantage of being able to "jump" one LTS, and still have a year of "old" validity before deploying "new".
Is there any chance of using a similar "release cycle" as far as LTS is concerned for Koha?
I sort of had something like this in mind when I was talking about "orphaned" vs. "killed". However, in terms of Koha, because there is no one maintaining 3.4.X, it can't be thought of as all stable versions are LTS. As for Ubuntu 8.04, even though it is LTS for Ubuntu, I don't think it is LTS for us. I purposefully wrote very discouraging remarks regarding it on the http://wiki.koha-community.org/wiki/Koha_on_Ubuntu page that I updated in the last couple of months. "DO NOT ATTEMPT TO INSTALL KOHA 3.8.X ON UBUNTU 8.04 -- IT FAILS! 3.6.X MAY FAIL TO INSTALL AS WELL." When I say "it fails!" I am implying that if you wanted it to work, it would go so seriously out of scope of these installation directions and be so specific for particular versions of OS and KOHA that it is not worth the effort (perl upgrades would be required, etcetera). I'm not a long term user, so my vote for 3.6.7 (soon to be released) does not carry as much weight. GPML, Mark Tompsett
participants (3)
-
Chris Cormack -
Mark Tompsett -
Paul