Stabilizing a release

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

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-rc1. 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:

Under some circumstances, the stabilization period will be extended. 

• If a potentially destabilizing change must be made in order to fix a bug, the entire four-week stabilization period is restarted. A potentially destabilizing change is one which could affect many parts of Fineract in unpredictable ways, or which involves adding a substantial amount of new code. Any incompatible API change (only allowable in the first place if the new release is an A.0.0 release) should be considered a potentially destabilizing change.

• If a critical bugfix is made during the final week of the stabilization period, the final week is restarted. The final A.B.0 release is always identical to the release candidate made one week before (with the exceptions discussed below).

If there are disagreements over whether a change is potentially destabilizing or over whether a bug is critical, they may be settled with a committer vote.

After the A.B.0 release is out, patch releases (A.B.1, A.B.2, etc.) follow when bug-fixes warrant them. Patch releases do not require a four week soak, because only conservative changes go into the line.  As long as changes are backwards compatible however, we prefer to put them into new minor releases rather than continue releasing patches for an old minor release.

Certain kinds of commits can go into A.B.0 without restarting the soak period, or into a later release without affecting the testing schedule or release date:

• Documentation fixes.
• Changes that are a normal part of release bookkeeping.

Core code changes, of course, require voting, and restart the soak or test period, since otherwise the change could be under-tested.

Voting

A change to the A.B.x line must be first proposed to the dev mailing list via a JIRA ticket.  The rest of the voting process takes place in JIRA.  The mail might look something like this: "I'm proposing to include the solution to ticket FINERACT-20045 in release 1.22.0.  I'm calling on all committers and interested contributors to join the discussion there." Please don't use dev@ for the actual discussion.  Conducting it in JIRA gives contributors the ability to opt out of individual discussions which don't interest them without opting out of the global FINERACT communication.

The ticket description should be enhanced to include a summary before the full description containing

• a brief description of the change
• an at-most-one-line justification of why it should be in A.B.x
• optionally some notes/concerns (brief summaries to help a reader get oriented – actual discussions take place in the ticket comments), and finally
• the votes.

Here's an example, probably as complex as an entry would ever get:

Summary
  Make a button which reads the user's mind.
Justification:
  It's what every user always wanted.
Notes:
  There was consensus on the desirability of this feature.
Concerns:
  Vetoed by myrle due to privacy concerns.
Votes (version A.B.x)
  +1: mage, gstein
  -1: myrle

A change needs three +1 votes from committers and no vetoes to go into A.B.x. If non-committers would like to vote it must be made clear in the voting section that their vote is 'non-binding' as follows:

Votes:
  +1: danielsh, hwright
  +1 (non-binding): stylesen

If you cast a veto (i.e. -1), please state the reason in the concerns field, and start the discussion on the ticket.  If you believe the information you are adding to the discussion is interesting for the broader community, also send a mail to dev that the issue is being discussed on ticket FINERACT-XYZ.

If you add revisions to a ticket, note that the previous voters have not voted for those revisions, as follows:

Votes (version 1.2.1)
  +1: mage, gstein
  -1: myrle
Votes (version 1.2.2)
  +1: mage

If in case votes have been communicated by means other than comments on the JIRA ticket means, note that in the summary.

Voting +1 on a change doesn't just mean you approve of it in principle. It means you have thoroughly reviewed the change, and find it correct and as nondisruptive as possible. When it is committed to the release branch, the log message will include the names of all who voted for it, as well as the original author and the person making the commit. All of these people are considered equally answerable for bugs.

If you've reviewed a patch, and like it but have some reservations, you can write "+1 (concept)" and then ask questions on the list about your concerns. You can write "+0" if you like the general idea but haven't reviewed the patch carefully. Neither of these votes counts toward the total, but they can be useful for tracking down people who are following the change and might be willing to spend more time on it.

(incomplete.  Working from http://subversion.apache.org/docs/community-guide/releasing.html)