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), ...

Example:

• 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.

Using Mercurial¶

Irccd uses 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
$ hg up

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 http://hg.malikania.fr/irccd

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 http://hg.malikania.fr/irccd

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
$ hg up

Stable and release branches¶

Example with stable-2

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