Follow development branch

Sometimes, you may want to follow a development branch instead of official releases. The general reasons are:

  • You develop irccd,
  • You want to try new feature / need a feature not already available,
  • You want the very last exciting features.

Version numbers

The general numbering scheme is x.y.z where x is a major version, y is the minor version and z is the patch version. See Semantic Versioning for more information.

Compatibility and changes

  • A minor version can add new features but never breaks compatibility. For example, if you have written a plugin with irccd 2.3, it must still work with irccd 2.9.
  • A major version can break everything as it is specified by the semantic versioning.

Note: semantic versioning is only fully honoured starting from irccd 2.0 version.

Releases process

Usually, only minor version are released unless we have to change a lot of things.

If everything goes well, releases follow the sequence x.y, x.(y + 1), ...


  • 1.0
  • 1.1
  • 1.2

However, if a bug is found in the current released version, it is fixed as soon as possible and a patch version is released. So if 1.8.0 is released and 1.9.0 is in development, we will have a release 1.8.1.

Development model

Irccd follow a development model with branches. At any time, irccd has always 3 branches. One called default, one called stable-x and one called release-x.y.

For instance, let say the current irccd release is 2.3.0 There will be the following branches:

  • release-2.3
  • stable-2
  • default

The first one, is the release branch of 2.3.z As 2.3.0 was released, the branch is frozen and get only fixes for typo, bug and such. No feature or breakage is added to this branch. This branch will be the parent of 2.3.1, 2.3.2 only.

The second one, stable-2 get regularly new features from default by specific merge commits named "Merge from default". No code should be committed on that branch, instead development is made in default and merged into this one. This branch is the parent of the next minor version (e.g. 2.4, 2.5)

The third, default, is the one where development takes place. It is discouraged to use it for production.

General users should always follow the release branch or eventually a stable branch.


We also sometimes use short-living bookmarks in the default branch. There is always a @ bookmark pointing to the revision that should be updated by default. When experimental features are in development, bookmarks can be placed on the default branch. In that case, the @ bookmark is usually older to avoid breakage for users.

You can think of @ bookmark as the reference for default branch. Thus when you want to switch from any branch to default, use hg update @ instead of hg up default.

Using Mercurial

We use exclusively Mercurial as our source control management. To clone a specific branch, you can use the -u flag

Following the default branch

If you just clone the repository without any flag, you will already have the default branch. If you have switched to other branch than default, you can switch back to it using:

$ hg pull -B @
$ hg up @

Note: since we use bookmarks, it is preferred to use @ identifier rather than default.

Following a stable branch

If you want to follow a stable branch and assuming the version in development is 2.1.

Use this for a fresh clone:

$ hg clone -u stable-2

Or this to switch:

$ hg update stable-1

Following a release branch

Again, this is the recommended branch to go with. Assuming the current released version is 2.1.4.

Use this for a fresh clone:

$ hg clone -u release-2.1

Or this to switch:

$ hg pull
$ hg update release-2.1

Syncing the sources

When you want to update the repository with upstream, you must use the hg pull and hg update commands. You can also use -u to hg pull to automatically updates the repository after fetching changesets.

For default branch

Longer version:

$ hg pull -B @
$ hg up @

Warning: do not use hg update with no arguments or hg pull -u as it may move bookmarks locally.

Stable and release branches

Example with stable-2

$ hg pull -b stable-2
$ hg up stable-2

Updated by David Demelier over 3 years ago · 28 revisions