tclnotmuch

Update of "SCM Notes"
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview

Artifact ID: a08d4b38128a5f0829b9bc90a054b3e6cc1ad3a2
Page Name:SCM Notes
Date: 2016-02-10 16:14:32
Original User: eric
Parent: 094727e226b39efe2f1871655a2ee58082cad205
Content

SCM for the tclnotmuch Project

Early Notes

Release Management and Branches

Note:
This may be seen as overkill for this project, but the project is being used as a prototype SCM exercise as well.

The project uses Semantic Versioning 2.0.0 with the minor variation that a version x.y.z having a z value of zero will be referred to as x.y.

There is no point in pre-release identifiers unless someone is using the version concerned, and build metadata, if needed, will be the first 10 characters of the SHA1 hash of the Fossil commit.

The project is currently in proof-of-concept mode, which will be labelled version 0.1, so the internal version labelling is set to this (including the .so name).

The first actual release will happen either

or

What to do in Fossil for a Release

The trunk Branch

This does not exist.

The mainline

When to Branch

  1. When the first patch to a release is required, check out the checkin tagged for the release, make changes and, on the first subsequent check in, make it a branch with the same name as the tag on the release (parent) checkin. This is a release maintenance branch and subsequent patches should be developed and released on this branch. Note that the new branch should be created even if the base release checkin has no child checkin yet.
  2. The above applies to pre-releases as well as normal non-patch releases.
  3. Parallel patch releases are not permitted.
  4. A pending branch may be created (from any mainline starting point) if work needs to start on a release beyond the next one planned. This should be named pending_intended-release, but the "intended release" is not binding, though the branch name should not be changed.
  5. An extra branch may be created for any need to separate some specific development. This branch may have any name that does not look like one of the other names above.

When to Merge

  1. A release maintenance branch is expected to be merged into mainline and to be closed at the time of the next mainline release.
  2. A pending branch is expected to be merged into mainline (or a release maintenance branch) and to be closed at the time of the next release on the receiving branch (which may be mainline).
  3. An extra branch is expected to be merged into mainline (or a release maintenance branch) and to be closed at the time of the next release on the receiving branch (which may be mainline).
  4. All three of the above may be merged a number of times and continue development after the merge (until their final merge).