|Pull requests and branches in a post 3.0 world||Hamish Friedlander||7/5/12 2:45 PM|
In preparation for 3.0.1 we've merged master back into the branches/3.0 branch. This is the only time we'll be doing this. From now on traffic will be one way - from branches/3.0 to master only. For clarity, the active branches are:
branches/3.0 - Where bug fixes and small new features that do not change APIs should go. This will be used as the source for the 3.0.x releases, and will be regularly merged into master
master - Where larger features and any changes that break APIs should go.
Additionally when we are preparing a new release we'll spin up a temporary branch for it. For instance, for the upcoming 3.0.1 release we'll spin up a new branch, branches/3.0.1. This will only hang around until 3.0.1 is out, then we'll tag it, merge it back into branches/3.0 and delete it. The reason for doing this is so we can limit changes to a particular release during the RC period without stuff that should end up in branches/3.0 going into master instead (like happened during the 3.0 release).
We may be requesting you re-raise pull requests against the correct branch from now on - especially if there's a merge issue. You can move a pull request to a new branch with this recipe:
git checkout new_branch_name
Please consider where you should be raising a pull request. In general, you should only be raising a pull request against master for anything that breaks APIs or is a big feature. Anything that you think should be in a 3.0.x release should go against branches/3.0