Release Maintainer for 3.2 Proposal

Overview

3.2 represents a significant advancement in the number and quality of features offered by Koha. With the valuable investment of both time and money in this growth by members of the community, the responsibility and stewardship of vigilant maintenance devolves upon the community. With that in mind, I propose the following:

  • that the 3.2 Release Maintainer become the point of convergence of the several maintenance efforts outlined below.
  • that regular consultation and coordination with the current Release Manager and Translation Manager be an integral part of the work of the Release Maintainer.
  • that a regular schedule of maintenance releases be published and maintained.
  • that after the next two subsequent stable releases of Koha, the developers meet and decide on an end-of-support (EOS) date for 3.2. By announcing and maintaining both a schedule of maintenance and, eventually, an EOS date, Koha support vendors, their customers, and the user community at large will be able to better plan their maintenance and migration schedules.

Proposed Schedule of Maintenance Releases

From 3.2.stable to 3.4.stable

Release once every 30 days or as bug fixes are available whichever is longer.

From 3.4.stable to X.X.stable

Release once very 90 days or as bug fixes are available whichever is longer.

After X.X.stable

Meet with developer's to decide on an EOS date. Release twice more: once mid-way to EOS and once at EOS.

Needed Areas of Maintenance

Back-porting Bug Fixes

With this growth will come the undesirable but inevitable appearance of bugs. The fixes for such bugs should be applied to the current development HEAD and back-ported to the 3.2 codebase.

Maintaining and Expanding Translations

The ever increasing exposure and usage of Koha across the world will lead to the need of updating and expanding the languages into which Koha is translated. This expansion should be part of the maintenance process in order to help enlarge the user base of Koha.

Minor Enhancement of the Current Set of Features

Undoubtedly there will appear from time to time enhancements of the current 3.2 feature set which it will be desirable to implement into the 3.2 code base. While it is not the purpose of 3.2 to morph into a semi-3.4 release, there should be some room for improvement. The regular maintenance release of 3.2 should include such items as appropriate.

 
en/development/relm3.2proposal.txt · Last modified: 2009/10/28 12:52 by fbcit
 
Except where otherwise noted, content on this wiki is licensed under the following license:CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki