Changes between Version 9 and Version 10 of FDORfc14


Ignore:
Timestamp:
04/25/08 09:28:56 (17 years ago)
Author:
gregboone
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • FDORfc14

    v9 v10  
    2525
    2626== The FDO Release Process ==
     27
    2728(Credit: Inspired by the !MapServer release process at http://mapserver.gis.umn.edu/development/rfc/ms-rfc-34/)
    2829
    … …  
    3738=== RFC Freeze Date ===
    3839
    39 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.
     40For 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.
    4041
    4142=== Feature Freeze Date / Beta Releases ===
    4243
    43 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 2-3 betas and a couple of release candidates over a 2 month period before the final release.
     44By 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.
     45
     46Since 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.
    4447
    4548=== Release Candidate ===
    4649
    47 Ideally, the last beta that was bug free. No changes to the code. 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 is issued.
     50Ideally, 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.
    4851
    4952=== Final Release / Expected Release Date ===
    5053
    51 Normally the last release candidate that was issued without any show-stopper bugs.
     54Normally the last release candidate that was issued without any show-stopper bugs that are considered critical to advertised functionality.
    5255
    5356=== Bug fix releases ===
    … …  
    7275
    7376Revisions are bug fixes only. No new functionality is provided in revisions.
     77
     78Typically, 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).
    7479
    7580== The FDO Release Manager Role ==
    … …  
    102107* Any of the above tasks can be delegated but they still remain the ultimate responsibility of the release manager.[[BR]]
    103108
     109The 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.
    104110