FDO RFC 14 – FDO Release Manager and Release Process
This page contains a request for comments document (RFC) for the FDO Open Source project. More FDO RFCs can be found on the RFCs page.
Status
| RFC Template Version | (1.0) |
| Submission Date | January 30, 2008 |
| Last Modified | Greg Boone Timestamp |
| Author | Greg Boone |
| RFC Status | Adopted |
| Implementation Status | Not Applicable |
| Proposed Milestone | 3.4.0.0 |
| Assigned PSC guide(s) | Greg Boone |
| Voting History | 2008-04-29 |
| +1 | Greg, Orest, Bob, Mateusz, Jason |
| +0 | |
| -0 | |
| -1 |
Overview
This RFC documents the FDO Release Manager role and the phases of FDO's Release Process
The FDO Release Process
(Credit: Inspired by the MapServer release process at http://mapserver.gis.umn.edu/development/rfc/ms-rfc-34/)
FDO aims to use a time-based release cycle, trying to aim for one release every 6 months.
The normal development process of a FDO release consists of various phases.
Development Phase
The development phase usually lasts around 4 months. New features are proposed via RFCs voted by the FDO PSC.
RFC Freeze Date
For each release there is a certain date by which all new feature proposals (RFCs) must have been submitted for review. After this date no features will be accepted anymore for this particular release. The RFC freeze typically occurs about 2 weeks before the planned Feature freeze date. RFCs that appear after the RFC freeze date, will be rolled into the next release.
Feature Freeze Date / Beta Releases
By this date all features must have been completed and all code has to be integrated. Only non-invasive changes, user interface work and bug fixes are done now. We usually plan for 1-2 betas and 1-2 release candidates over a 2 month period before the final release. Features that have not been completed by the Feature freeze date wait should not be committed to the trunk until after the trunk has been released.
Since we're not in a perfect world, there are always exceptions, and in case some components cannot be completed in time for the feature freeze then they should either be disabled (#ifdef'd by default), or left active and called experimental in the release notes.
Release Candidate
Ideally, the last beta where no major defect have been encountered (show-stopper) or where defects identified have been assessed. Should not require any migration steps apart from the ones required in the betas. If any problems are found and fixed, a new release candidate should be issued.
Final Release / Expected Release Date
Normally the last release candidate that was issued without any show-stopper bugs that are considered critical to advertised functionality.
Bug fix releases
No software is perfect. Once a sufficient large or critical number of bugs have been found for a certain release, the release manager releases a new bug fix release a.k.a. third-dot release (for example 3.3.1).
FDO Version Numbering
FDO's version numbering scheme is very similar to Linux's. For example, an FDO version number of 3.2.1 can be decoded as such:
3: Major version number
We release a major version every two to three years. The major version number usually changes when significant new features are added or when major architectural changes or backwards incompatibilities are introduced.
2: Minor version number
Increments in minor version number almost always relate to additions in functionality and correspond to the 6 months release process described in this RFC.
FDO does NOT uses the same even/odd minor version number scheme as Linux. Even minor version numbers do NOT relate to release versions, and odd minor versions do NOT correspond to developmental versions.
1: Revision number
Revisions are bug fixes only. No new functionality is provided in revisions.
Typically, a primary objective is to try to maintain binary compatibility within the same minor version number and certainly between revision number (e.g. 3.3.0 and 3.3.1 are binary compatible). The same statement will be in effect for schemas (XML, file format or db).
The FDO Release Manager Role
For every release of FDO, the PSC elects a release manager (this is usually done with a motion and vote on the fdo-internals list).
The overall role of the release manager is to coordinate the efforts of the 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 the feature freeze
- Maintaining the release schedule (timeline) and making changes as required
- When in doubt or for tough decisions (e.g. pushing the release date by several weeks) the release manager is free to ask the PSC to vote in support of some decisions, but this is not a requirement for the areas of responsibility above.
The release manager's role also includes the following tasks:
- Setup and maintain the Release Plan section of the website for this release
- Coordinate with Contributors/Developers
- Coordinate with Testers
- Manage Documentation/Website
- Keep track of progress via Trac (make use of Trac milestones and ensure tickets are properly targeted, push some tickets to a later release if required, etc.)
- Organize regular IRC meetings (including agenda and minutes)
- Tag source code in SVN for each beta, RC and release
- Branch source code in SVN after the final release (trunk becomes the next dev version)
- Package source code distribution for each beta/RC/release
- Update appropriate website/download page for each beta/RC/release
- Make announcements on fdo-users and fdo-announce for each release
- Produce/coordinate bugfix releases as needed during the 6 months period that follows the final release (i.e. until the next release)
- Any of the above tasks can be delegated but they still remain the ultimate responsibility of the release manager.
The RFC freeze date, Feature freeze date and a Final release date will be recommended by the Release Manager and voted on by the PSC in a motion. It will be the release manager's job to try to make the release follow those dates.
