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

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. 

...

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 first 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 that we 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@ the mailing list 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

...

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.

A vote should be added to the bottom of the ticket description with the following information:

• 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),
• optionally some concerns (again, brief summaries) and finally
• the votes and vetoes.

If you cast a veto (i.e. -1), please summarize the reason in the concerns field, and start the discussion by commenting on the JIRA ticket.

Voting +1 on a change means that you have reviewed the change using the community guidelines for code reviews. The +1 voters, the proposer, the programmer, and the committer that pulls a change into a release are all equally responsible for any resulting bugs.

Non-committers are welcome to vote via the JIRA ticket comments, thus taking on shared responsibility for a change.  Their vote is non-binding.

If you add revisions to a ticket, you can create a new block and skip any sections that are redundant.  Use the same schema if you want to vote a change into a later release.  You might want to do this if you believe it requires further review or testing.

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

...

:

Proposed for version 1.2.1 by @mage
Justification:
  

...

Mindreading is what every user always wanted.
Notes:
  There was consensus on the desirability of this feature.
Concerns:
  Vetoed by 

...

@myrle due to privacy concerns.
Votes

...

:
  +1: 

...

@mage, 

...

@gstein
  +1: (non-binding): @stylesen
 -1: 

...

@myrle

Proposed for version 1.3.0 by @myrle
Justification:
  We should be able to isolate it to the prefrontal cortex with another month of development effort.
Votes:
  +1: @myrle

Votes are only communicated by comments on the JIRA ticket, and not by any other means.

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 or someone else is adding to the discussion is interesting for the broader community, also please 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, have reviewed a change 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 and communicate concerns using the JIRA ticket comments. If you wish to track down people who are following the change and might be willing to spend more time on it, the watcher list on its JIRA ticket is a good place to start.

(Thanks to the Subversion team for the content and ideas we 'borrowed' from the Subversion release guideline)

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