On Wed, Oct 28, 2009 at 6:40 PM, LAURENT Henri-Damien <henridamien.laurent@biblibre.com> wrote:
MJ Ray a écrit :
Also, Chris Cormack asked about changing the homepage to link to 3.00.04, but so far we haven't heard from HDL about his intentions to roll 3.00.05 to fix the previous issues with 3.00.04 and 3.00.04_final, and to provide a single download point for this release. To avoid further user confusion I suggest we await his comments on that.
OK - HDL? (And had anyone asked you before this?)
Well, noone asked me to update the home page, and as far as koha.org is concerned, and I **cannot** (don't have permissions on page to) do that. About download.koha.org, and the numbering, I was really very recently asked to increase the number rather than add a tag after the name. And I agree with that. But the fact is that since the release still counted a few problems owed to the complexity of the conflicts management and modules and scripts and templates we use, with all the bug fix patches in a really short amount of time, and testing those changes on a wide variety of system preferences. And those problems required a fix. Why did you publish and publicly announce a release that hadn't been tested?
Your excuse for why this release is/was so buggy reinforces the fact that good release management/maintenance needs to focus on producing _quality_ releases and that this idea of 'release often release early' is NOT the appropriate strategy if the software is broken. If a release is going to be complex, please roll alpha/beta versions of it so that it can be tested, as we did with 3.00.00. You've put independent libraries running 3.0 and solutions like LibLime's Koha Express, in an awkward position because we know that 3.00.04 and 3.00.04_final are not really stable, production-ready releases. For the record, its not the first time since the 3.00.00 release that this has happened. We need some assurance from you that this won't happen again!
I would have rather keep the name of the initial release and change the tag position in the tree, and replace the release tarball with the fixed one. Since I would not want a non stable version to be kept in history. The quicker the fixed version would have been up, the better it would have been. But the right I have on tags is limited. And I had been once suggested to post-fix the release number with some comment. And the access on download.koha.org I had was limited since I could only upload the version on a private place on the server and Liblime had to move the files uploaded into public directory. And that access has even been closed just after the first 3.00.04 release.
If you ask about 3.00.05, I propose to set one quite soon in order to stick to the principle release early, release often. Better a release which counts a few patches, which work than a release which counts lots and does have some problems.
But for now, the 3.00.04_final is the latest stable release and it would be nice if koha.org pointed to that. We've adjusted the front page to point to the _final release since it is less buggy than the original 3.00.04 release you produced. However, just for the record, LibLime's community solutions such as the Koha Express platform are going to skip this release for its bugs and hold off until 3.00.05 to see if they are resolved.
Cheers, Josh
Thanks. -- Henri-Damien LAURENT Release Maintainer
-- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS