Release Policy

[sque]

The time has come that more than one developer has to agree upon a policy on how to make releases. This involves the dates, the features, the versioning, the tasks. A good start was done at the meeting of (27 Dec @ hsgr ).

The purpose of this ticket is to discuss what would be the policy and write it down to a wiki page

Bellow the bar you will find an almost complete proposal based on the meeting and my assumptions. Feel free to argue!

---

Versioning

Till now it was implictly assumed that we follow the Sematic Versioning where it defines what is expected to be found in each release. Briefly, a patch version change means small bug fixes, a minor version change means backward compatible changes, and major version change means API breakage or anything else.

Branches

At the meeting of 27 Dec, it was proposed that all developpers work on master branch for one or two commit changes. If something takes long time and requires a lot of commits it should become a different branch with a descriptive name like ipv6. This branch can be located in a user repository, but if it is something big, that multiple developers could work, it should be in the main repository.
For each minor release we should keep a different branch like v1.2-series. At this branch we should cherry pick bug fixes from the master branch. This branch will be used for the next patch release.

Merging

Every branch that is complete should be merged back to master. The merging should be done by following the github procedure of pull request. All the pull requests should be processed by the pull request responsibe devellopers. Who will be these devellopers, is a matter of the team decision, but selecting one or two persons will solve the confusion of the merging procedure.

Major&Minor Releases

All major and minor releases should come from the master branch. The general concept is that when all issues of a milestone are closed, then the branch should freeze. After a small freeze period and when there is no know bug, the branch should be tagged with a version like v1.4.0 (notice that patch version should be zero) and a release should be made on this tag. Then the developement on master can continue..

Patch Releases

For every active minor serie a milestone will be created with a due date of 30 days after the last release. At the end of the due date, if there are any commits since last release, then the series branch (e.g. v1.2-series) should be tagged with next patch version like v1.2.4 and a new release should be made. After the release a new milestone should start for the next patch release (e.g. 1.2.5) with due date 30 days later.
If a bug fix is critical, an exception for earlier release can be made.

[sque]

bump!
There was no opinion expressed in this bug, and it is crucial to establish a release policy. I would like to create v1.0-series branch so that I can checrry pick fixed bugs, but I would like to see your opinions first.

[nikalexis]

+1

On Sun, Jan 5, 2014 at 2:53 PM, sque [email protected] wrote:

bump!
There was no opinion expressed in this bug, and it is crucial to establish
a release policy. I would like to create v1.0-series branch so that I can
checrry pick fixed bugs, but I would like to see your opinions first.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-31603465
.

[acinonyx]

My thoughts:

Branches

Diverting from "master" always creates a branch in Git. The difference is wether you want the branch publicized, before it becomes ready. The criteria should not be the number of commits or the time it takes to complete a feature, but the quality of the code changes and if they are good enought to get public. This means that the branch should be in a shape where other developers are able to contribute, otherwise publicizing it is useless.

Major&Minor Releases

Master branch should always be the latest and never freeze. We can always tag a release candidate from it and branch if we need to backport some fixes for bugs later discovered. Normally, we could end up for a branch for each minor release. Each of these branches would usually contain backported fixes preparing the next patch release.

[ysamouhos]

+1