Differences between revisions 1 and 2
Revision 1 as of 2013-02-07 19:40:43
Size: 951
Editor: AndrewGrieve
Comment:
Revision 2 as of 2013-05-09 14:50:36
Size: 1121
Comment: Update for the modern master+2.7.x style of branching.
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Cordova repositories have two main branches: Cordova repositories have a main development branch, `master`.
Line 5: Line 5:
 1. master
 2. next
There are also one or more long-lived branches, named after a minor revision, eg. `2.7.x`. Tags on these release branches will identify individual releases and release candidates:
Line 8: Line 7:
Transient branches that may exist:
 * Topic branches - exist for collaborating on features, or for code-review purposes.
 * Maintenance Release Branches - exist as "next" branches for maintenance releases (e.g. 2.4.1)
 * `2.7.0rc1`
 * `2.7.0rc2`
 * `2.7.0`
 * `2.7.1rc1`
 * `2.7.1`
 * ...
Line 12: Line 14:
Cordova uses tags to label releases.
 * Each release candidate has a tag. e.g. "2.2.0rc1"
 * Each release has a tag. e.g. "2.2.0"
 * The "latest" tag points to the last stable release (this follows npm conventions)
Currently there is also a `3.0.0` branch, where porting to the new style of separated, cross-platform plugins is underway.
Line 17: Line 16:
Transient topic branches for collaborating on features, or for code-review purposes, may exist from time to time.
Line 18: Line 18:
1. The "next" branch. At the start of a new release, `master` is forked to become `2.8.x`. Testing is performed, and a release candidate is tagged on the branch.
Line 20: Line 20:
 * This branch is used only when in the process of doing a release.
 * All tags are created from this branch.
 * All release-candidate bug-fixes are done on this branch.
No merges are performed between `2.8.x` and `master`, in either direction, ever. It makes a mess of the history.
Line 24: Line 22:
2. The "master" branch. Instead, all new changes should be committed to `master`, and then cherry-picked into `2.8.x` if, and only if, they are bugfixes to release-blocking bugs. Otherwise they should wait in `master` for the next release.
Line 26: Line 24:
 * When not in the release-process, all commits are made here
 * When in the release-process, all non-bugfix commits are made here
 * This is where topic-branches are merged into.
Don't merge between the branches. Don't do it.

Cordova and Git

Cordova repositories have a main development branch, master.

There are also one or more long-lived branches, named after a minor revision, eg. 2.7.x. Tags on these release branches will identify individual releases and release candidates:

  • 2.7.0rc1

  • 2.7.0rc2

  • 2.7.0

  • 2.7.1rc1

  • 2.7.1

  • ...

Currently there is also a 3.0.0 branch, where porting to the new style of separated, cross-platform plugins is underway.

Transient topic branches for collaborating on features, or for code-review purposes, may exist from time to time.

At the start of a new release, master is forked to become 2.8.x. Testing is performed, and a release candidate is tagged on the branch.

No merges are performed between 2.8.x and master, in either direction, ever. It makes a mess of the history.

Instead, all new changes should be committed to master, and then cherry-picked into 2.8.x if, and only if, they are bugfixes to release-blocking bugs. Otherwise they should wait in master for the next release.

Don't merge between the branches. Don't do it.

CordovaAndGit (last edited 2013-05-09 14:50:36 by Braden Shepherdson)