SCM: Difference between revisions
Jump to navigation
Jump to search
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
== |
== ChangeLog == |
||
* [http://www.gnu.org/prep/standards/html_node/Change-Logs.html GNU ChangeLog Standard] |
|||
== SCM Examples == |
|||
=== Trunk is next enhancement release === |
=== Trunk is next enhancement release === |
||
From [http://developers.slashdot.org/comments.pl?sid=1889790&cid=34393324]: |
From [http://developers.slashdot.org/comments.pl?sid=1889790&cid=34393324]: |
||
| Line 18: | Line 21: | ||
=== Branch from a stable baseline === |
=== Branch from a stable baseline === |
||
See http://codicesoftware.blogspot.com/2010/11/linus-on-branching.html. |
See http://codicesoftware.blogspot.com/2010/11/linus-on-branching.html. |
||
== Versioning system == |
|||
* [https://semver.org/ Semantic Versioning] |
|||
:Proposed by GitHub cofounder, Semantic Versioning codes version number as MAJOR.MINOR.PATCH, where each part gives information about API compatibility with respect to previous versions. |
|||
Latest revision as of 12:28, 10 January 2017
ChangeLog
SCM Examples
Trunk is next enhancement release
From [1]:
- The trunk was always the next enhancement release--assumed unstable at all times.
- When we were ready to test that release, we would branch the trunk.
- From that point forward, new development would be done on the trunk again and only fixes would go into the release branch.
- Once we had the release branch stable enough to release, we would tag it and cut a release.
- A release branch would wind up with one or more "maintenance releases," so each time we wanted to have one of those we'd make a branch off of the release branch. Fixes not destined for the current maintenance release would go on the upstream branch to be part of the next one.
- All fixes were merged upstream using a custom merge tool.
Clients were able to cherry-pick what patches they wanted, too, and we would merge those fixes into a custom branch (based on their installed release) and cut a patch release. We had a system that tracked dependencies so the defect rate was quite low with this process. If a given fix had too many dependencies we'd force the customer to take the next maintenance release.
At any given time, we maintained an enhancement branch (trunk), at least two major release branches, and then we usually supported the last two maintenance releases on each major release branch.
Branch from a stable baseline
See http://codicesoftware.blogspot.com/2010/11/linus-on-branching.html.
Versioning system
- Proposed by GitHub cofounder, Semantic Versioning codes version number as MAJOR.MINOR.PATCH, where each part gives information about API compatibility with respect to previous versions.