|
⇤ ← Revision 1 as of 2013-02-07 19:40:43
Size: 951
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.