Changes between Initial Version and Version 1 of ReleaseManagementPrelim

Timestamp:

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

Author:

hobu

Comment:

--

ReleaseManagementPrelim

@@ +1 @@
+{{{
+#!rst
+==============================================================================
+GDAL Release Management Process
+==============================================================================
+
+:Author: Howard Butler
+:Contact: hobu.inc@gmail.com
+:Date: 2007-12-04
+
+.. sectnum::
+
+.. contents::
+    :depth: 3
+    :backlinks: top
+
+This document steals heavily from MapServer `MS RFC 34`_, written by 
+Daniel Morissette.
+
+
+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.  
+
+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.
+
+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.
+
+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.  
+
+
+Major Release Process
+---------------------
+
+We're. not. having. one. 
+
+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:
+
+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.
+
+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.
+
+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.
+
+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.
+
+Beta 2, 3, ..., X
+..................
+
+Betas after Beta 1 are left to the discretion of the release manager to 
+produce and announce.
+
+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. 
+
+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.  
+
+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
+}}}