Page History

Stabilization

Minor and major number releases go through a stabilization period before release, and remain in maintenance (bugfix) mode after release. To start the release process, we create an "A.B.x" branch based on the latest master.

The stabilization period for a new A.B.0 release normally lasts four weeks, and allows us to make conservative bugfixes and discover showstopper issues. The stabilization period begins with a release candidate with the version A.B.0-rc1rc.1. Further release candidates may be made as blocking bugs are fixed.

At the beginning of the final week of the stabilization period, a new release candidate should be made if there are any showstopper changes pending since the last one. The final week of the stabilization period is reserved for critical bugfixes; fixes for minor bugs should be deferred to the A.B.1 release.

In these respects we are using the same release process as Subversion:

...

A picture speaks a thousand words:

Under some circumstances, the stabilization period will be extended. 

...

Before proposing adding a change, you should check that it doesn't produce merge conflicts in the master branch. If conflicts occur, please create a new temporary branch in your fork with your changes merged and the conflicts resolved. The branch should be named A.B.x-YYYY, where YYYY is the number of the FINERACT JIRA ticket. Add a note in the JIRA ticket about the existence of the temporary branch and which fork it can be found in. If the change involves further work, that work can be performed on the branch.

In order to make it possible to find all tickets in a given release, please make sure the fix version on the JIRA ticket is set. While a ticket is in voting, add the label "submitted_for_vote" to the ticket.  Once the vote is complete, remove the label.  If the ticket is voted out, change the fix version appropriately.

A change needs three +1 votes from committers and no vetoes to go into A.B.x.

...