Changes between Initial Version and Version 1 of ReleaseManagementPrelim


Ignore:
Timestamp:
Dec 4, 2007 8:39:07 AM (12 years ago)
Author:
hobu
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ReleaseManagementPrelim

    v1 v1  
     1{{{
     2#!rst
     3==============================================================================
     4GDAL Release Management Process
     5==============================================================================
     6
     7:Author: Howard Butler
     8:Contact: hobu.inc@gmail.com
     9:Date: 2007-12-04
     10
     11.. sectnum::
     12
     13.. contents::
     14    :depth: 3
     15    :backlinks: top
     16
     17This document steals heavily from MapServer `MS RFC 34`_, written by
     18Daniel Morissette.
     19
     20
     21Version Management
     22------------------
     23
     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. 
     29
     30Major
     31.....
     32
     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.
     38
     39Minor
     40.....
     41
     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.
     49
     50Revision
     51........
     52
     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. 
     60
     61
     62Major Release Process
     63---------------------
     64
     65We're. not. having. one.
     66
     67Minor Release Process
     68---------------------
     69
     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:
     73
     74Development
     75...........
     76
     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.
     81
     82Pre-release Meeting
     83...................
     84
     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.
     92
     93RFC Freeze
     94..........
     95
     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.
     101
     102Beta 1
     103......
     104
     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.
     112
     113Beta 2, 3, ..., X
     114..................
     115
     116Betas after Beta 1 are left to the discretion of the release manager to
     117produce and announce.
     118
     119Release Candidate
     120.................
     121
     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.
     127
     128Final Release
     129.............
     130
     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. 
     135
     136Release Manager Duties and Responsibilities
     137-------------------------------------------
     138
     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:
     146
     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.
     152
     153The release manager's role also includes the following tasks:
     154
     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`_.
     159
     160Any of the above tasks can be delegated, but they remain the ultimate
     161responsibility of the release manager.
     162
     163_`MS RFC 34`: http://mapserver.gis.umn.edu/development/rfc/ms-rfc-34/
     164_`RFC 1`: http://trac.osgeo.org/gdal/wiki/rfc1_pmc
     165_`RFC 3`: http://trac.osgeo.org/gdal/wiki/rfc3_commiters
     166_`Trac Roadmap`: http://trac.osgeo.org/gdal/roadmap
     167_`release procedures document`: http://trac.osgeo.org/gdal/browser/trunk/gdal/HOWTO-RELEASE
     168}}}