Changes between Version 8 and Version 9 of WorkingConventions/Releases


Ignore:
Timestamp:
Sep 9, 2013 6:40:26 AM (23 months ago)
Author:
heisenbug
Comment:

make this more current

Legend:

Unmodified
Added
Removed
Modified
  • WorkingConventions/Releases

    v8 v9  
    5353The `master` branch of all repositories is the main development branch.  We often call this "HEAD" for historical reasons.
    5454
    55 There 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`.
     55There is a '''stable branch''' corresponding to each major release, named after the major version.  For example, the stable branch corresponding to the 7.8 series of releases is called `ghc-7.8`.  Every repository (see [wiki:Repositories]) has a `ghc-7.8` branch, so you can switch a complete tree to the branch with `./sync-all checkout ghc-7.8`.
    5656
    57 '''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`.
     57'''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.8.1`.
    5858
    5959'''Only the release manager modifies the stable branch.'''  Other developers request that changes are merged to the branch in one of the following ways:
     
    6363 * By emailing the release manager to ask that a patch be merged.  This is appropriate when there isn't a ticket corresponding to the patch.
    6464
    65 The release manager will usually merge patches with `git cherry-pick`, so patches on the branch will have different SHA-1 hashes from their corresponding patches on `master`.  This means that you can't use tricks like `git name-rev` to see whether a particular patch is on the branch - just search through the output of `git log ghc-7.4` instead.
     65The release manager will usually merge patches with `git cherry-pick`, so patches on the branch will have different SHA-1 hashes from their corresponding patches on `master`.  This means that you can't use tricks like `git name-rev` to see whether a particular patch is on the branch - just search through the output of `git log ghc-7.8` instead.
    6666