GDAL Release Management Process
| Author: | Howard Butler |
|---|---|
| Contact: | hobu.inc@gmail.com |
| Date: | 2007-12-04 |
Contents
This document steals heavily from MapServer MS RFC 34, written by Daniel Morissette.
1 Version Management
GDAL uses a typical major.minor.revision (eg, 1.5.0) release numbering scheme with the major release limited to containing drastic API or behavioral changes (very few to date), the minor release typically being the annual or semi-annual release containing new features and drivers, and the revision release containing backported fixes to a maintenance branch.
1.1 Major
The project desires to have very few major releases, as maintaining a rigorously backwards compatible API is a long-standing goal of the project. A major release is expected to be highly disruptive to client software, and it is expected that only large scale architectural re-engineering would precipitate a major release. We're. not. having. one.
1.2 Minor
The project desires to have an annual or semi-annual minor release that is limited to new features, slight structural enhancements, new APIs (no removals), and re-engineering of the library's subsystems. It is expected that the minor release will happen no earlier than every six (6) months and no later than one (1) year, periodically. Continuing development within the main development trunk is expected to be tracking what will ultimately be the next minor release.
1.3 Revision
The project desires to have revision releases (maintenance releases) of the previously released minor release every two (2) to six (6) months, periodically, until a revision release of the current minor release has been made. For example, if the 1.4 maintenance branch contains a continuing stream of revision releases -- 1.4.1, 1.4.2, ..., 1.4.4 -- and the 1.5.0 minor release was made, maintenance in the 1.4 branch would continue until a 1.5.1 maintenance release was produced.
2 Major Release Process
We're. not. having. one.
3 Minor Release Process
GDAL's minor release cycle is time-based. The normal development process of a GDAL minor release consists of various phases, with the close of the development phase to final release taking typically one (1) month:
3.1 Development
Continuing development within the main trunk of svn according to the committer guidelines described in RFC 1 and RFC 3. Both feature development and bug fix activity happen in trunk during this period, which may last anywhere from five (5) to eleven (11) months.
3.2 Pre-release Meeting
After development momentum appears to slow, or at what looks like a natural release point, a PSC member or committer should call for the pre-release meeting. The purpose of this meeting is to select the release manager for the minor release and coordinate activities that need to be completed. These activities include setting any additional meetings, specifying deadlines such as the RFC Freeze and Beta 1, and fleshing out the expected timetable the project will take as it marches toward release.
3.3 RFC Freeze
Changes or additions that would require an RFC under the guidelines of RFC 1 need not be complete by the RFC Freeze date, but the RFC should be posted for general review by this date. Late additions or significant changes to existing RFCs should be handled by the release manager on a case-by-case basis.
3.4 Beta 1
Beta 1 signals that feature development within the minor release branch has been completed and developers are working toward polishing the current codebase in expectation of the release. During the beta period, outstanding bugs left on the release milestone in Trac Roadmap should be completed or pushed off until the next release. Bug triage is the responsibility of the release manager to delegate or assume as new bugs continue to stream in from the beta process.
3.5 Beta 2, 3, ..., X
Betas after Beta 1 are left to the discretion of the release manager to produce and announce.
3.6 Release Candidate
It is the responsibility of the release manager to bring forward the release candidate by producing a tarball and by motioning to the mailing list. If any significant problems are found and fixed, the motion may be retracted, and a new release candidate may be issued. The decision forge ahead with the release in the face of minor issues is at discretion of the release manager.
3.7 Final Release
After a release candidate has been issued and two (2) business days have passed without significant issues, the release manager will package up the final release and complete the activities listed in the release procedures document that lives in svn.
4 Release Manager Duties and Responsibilities
For every minor release of GDAL, the PSC elects a release manager (this is usually done at the pre-release meeting in IRC). The overall role of the release manager is to coordinate the efforts of developers, testers, documentation, and other contributors to lead to a release of the best possible quality within the scheduled timeframe. The PSC delegates to the release manager the responsibility and authority to make certain final decisions for a release, including:
- Approving or not the release of each beta, release candidate, and final release.
- Approving or rejecting non-trivial bug fixes or changes after Beta 1
- Maintaining the release schedule (timeline) and making changes as required.
The release manager's role also includes the following tasks:
- Setup and maintain the Trac Roadmap for the release, prioritizing bugs, and coordinating with developers.
- Organize regular IRC meetings (including agenda and minutes)
- Complete the tasks described in the release procedures document.
Any of the above tasks can be delegated, but they remain the ultimate responsibility of the release manager.
MS RFC 34: http://mapserver.gis.umn.edu/development/rfc/ms-rfc-34/ RFC 1: http://trac.osgeo.org/gdal/wiki/rfc1_pmc RFC 3: http://trac.osgeo.org/gdal/wiki/rfc3_commiters Trac Roadmap: http://trac.osgeo.org/gdal/roadmap release procedures document: http://trac.osgeo.org/gdal/browser/trunk/gdal/HOWTO-RELEASE
