Changes between Version 2 and Version 3 of WorkingConventions/Releases


Ignore:
Timestamp:
Aug 24, 2012 9:49:33 AM (20 months ago)
Author:
simonmar
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WorkingConventions/Releases

    v2 v3  
    2424There is a '''stable branch''' corresponding to each major release, named after the major version.  For example, the stable branch corresponding to the 7.4 series of releases is called `ghc-7.4`.  Every repository (see [wiki:Repositories]) has a `ghc-7.4` branch, so you can switch a complete tree to the branch with `./sync-all checkout ghc-7.4`. 
    2525 
    26 Releases are only made from the stable branch.  The stable branch for a major release is created by the release manager shortly before the release candidate (a couple of weeks or so).  When the release is made, the stable branch (of all repositories) is tagged with the release name, e.g. `ghc-7.4.1`. 
     26'''Releases are only made from the stable branch.'''  The stable branch for a major release is created by the release manager shortly before the release candidate (a couple of weeks or so).  When the release is made, the stable branch (of all repositories) is tagged with the release name, e.g. `ghc-7.4.1`. 
    2727 
    28 Our convention is that only the release manager modifies the stable branch.  Other developers request that changes are merged to the branch in one of the following ways: 
     28'''Only the release manager modifies the stable branch.'''  Other developers request that changes are merged to the branch in one of the following ways: 
    2929 
    3030 * By moving a ticket into the "merge" state once it is fixed.  Please do this if you fix a bug and the fix is suitable for the branch.  Check that the milestone field of the ticket identifies the correct release target. This helps later on when we need to know whether a bug was fixed in a particular release, and also helps us to collect a list of all bugs that were fixed in a given release.