THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
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:
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
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.
...