Changes between Initial Version and Version 1 of ReleaseManagementPrelim

Dec 4, 2007, 8:39:07 AM (12 years ago)



  • ReleaseManagementPrelim

    v1 v1  
     4GDAL Release Management Process
     7:Author: Howard Butler
     9:Date: 2007-12-04
     11.. sectnum::
     13.. contents::
     14    :depth: 3
     15    :backlinks: top
     17This document steals heavily from MapServer `MS RFC 34`_, written by
     18Daniel Morissette.
     21Version Management
     24GDAL uses a typical major.minor.revision (eg, 1.5.0) release numbering scheme
     25with the major release limited to containing drastic API or behavioral
     26changes (very few to date), the minor release typically being the annual
     27or semi-annual release containing new features and drivers, and the revision
     28release containing backported fixes to a maintenance branch. 
     33The project desires to have very few major releases, as maintaining a
     34rigorously backwards compatible API is a long-standing goal of the project. 
     35A major release is expected to be highly disruptive to client software, and
     36it is expected that only large scale architectural re-engineering would
     37precipitate a major release.  We're. not. having. one.
     42The project desires to have an annual or semi-annual minor release that is
     43limited to new features, slight structural enhancements, new APIs (no
     44removals), and re-engineering of the library's subsystems.  It is expected
     45that the minor release will happen no earlier than every six (6) months
     46and no later than one (1) year, periodically.  Continuing development
     47within the main development trunk is expected to be tracking what will
     48ultimately be the next minor release.
     53The project desires to have revision releases (maintenance releases) of
     54the previously released minor release every two (2) to six (6) months,
     55periodically, until a revision release of the current minor release
     56has been made.  For example, if the 1.4 maintenance branch contains a continuing
     57stream of revision releases -- 1.4.1, 1.4.2, ..., 1.4.4 -- and the 1.5.0
     58minor release was made, maintenance in the 1.4 branch would continue until a
     591.5.1 maintenance release was produced. 
     62Major Release Process
     65We're. not. having. one.
     67Minor Release Process
     70GDAL's minor release cycle is time-based.  The normal development process of
     71a GDAL minor release consists of various phases, with the close of the
     72development phase to final release taking typically one (1) month:
     77Continuing development within the main trunk of svn according to the
     78committer guidelines described in `RFC 1`_ and `RFC 3`_.  Both feature
     79development and bug fix activity happen in trunk during this period,
     80which may last anywhere from five (5) to eleven (11) months.
     82Pre-release Meeting
     85After development momentum appears to slow, or at what looks like a
     86natural release point, a PSC member or committer should call for the
     87pre-release meeting.  The purpose of this meeting is to select the release
     88manager for the minor release and coordinate activities that need to be
     89completed.  These activities include setting any additional meetings,
     90specifying deadlines such as the RFC Freeze and Beta 1, and fleshing out
     91the expected timetable the project will take as it marches toward release.
     93RFC Freeze
     96Changes or additions that would require an RFC under the guidelines
     97of `RFC 1`_ need not be complete by the RFC Freeze date, but the RFC should
     98be posted for general review by this date.  Late additions or significant
     99changes to existing RFCs should be handled by the release manager on a
     100case-by-case basis.
     102Beta 1
     105Beta 1 signals that feature development within the minor release
     106branch has been completed and developers are working toward polishing the
     107current codebase in expectation of the release.  During the beta period,
     108outstanding bugs left on the release milestone in `Trac Roadmap`_ should be
     109completed or pushed off until the next release.  Bug triage is the
     110responsibility of the release manager to delegate or assume as new bugs
     111continue to stream in from the beta process.
     113Beta 2, 3, ..., X
     116Betas after Beta 1 are left to the discretion of the release manager to
     117produce and announce.
     119Release Candidate
     122It is the responsibility of the release manager to bring forward the
     123release candidate by producing a tarball and by motioning to the mailing list.
     124If any significant problems are found and fixed, the motion may be retracted,
     125and a new release candidate may be issued.  The decision forge ahead with
     126the release in the face of minor issues is at discretion of the release manager.
     128Final Release
     131After a release candidate has been issued and two (2) business days have
     132passed without significant issues, the release manager will package up the
     133final release and complete the activities listed in the `release procedures document`_
     134that lives in svn. 
     136Release Manager Duties and Responsibilities
     139For every minor release of GDAL, the PSC elects a release manager (this is
     140usually done at the pre-release meeting in IRC).  The overall role of the
     141release manager is to coordinate the efforts of developers, testers,
     142documentation, and other contributors to lead to a release of the best
     143possible quality within the scheduled timeframe.  The PSC delegates to the
     144release manager the responsibility and authority to make certain final
     145decisions for a release, including:
     147  * Approving or not the release of each beta, release candidate,
     148    and final release.
     149  * Approving or rejecting non-trivial bug fixes or changes after Beta 1
     150  * Maintaining the release schedule (timeline) and making changes as
     151    required.
     153The release manager's role also includes the following tasks:
     155  * Setup and maintain the `Trac Roadmap`_ for the release, prioritizing
     156    bugs, and coordinating with developers.
     157  * Organize regular IRC meetings (including agenda and minutes)
     158  * Complete the tasks described in the `release procedures document`_.
     160Any of the above tasks can be delegated, but they remain the ultimate
     161responsibility of the release manager.
     163_`MS RFC 34`:
     164_`RFC 1`:
     165_`RFC 3`:
     166_`Trac Roadmap`:
     167_`release procedures document`: