Draft proposal for way of working with stable branches and doing maintenance
The page is derived from https://wiki.openstack.org/wiki/StableBranch , simplified and adapted to OPNFV.

At this time only Arno release maintenance is covered.

The stable branch is intended to be a safe source of fixes for high impact bugs and security issues which have been fixed on master since a given release. It allows users of release (stable) versions to benefit from the ongoing bugfix work after the release.

Official point releases for each project are published from the branch on a per need basis, as decided by the TSC. In later stages, a regular cadence for point releases may be introduced.

It's possible to check current maintained versions in the releases page. At this time only Arno is maintained.

OPNFV's stable branch policy borrows much from prior art, in particular from OpenStack.

Only a limited class of changes are appropriate for inclusion on the stable branch.

A number of factors must be weighed when considering a change:

• The risk of regression - even the tiniest changes carry some risk of breaking something and we really want to avoid regressions on the stable branch
• The user visible benefit - are we fixing something that users might actually notice and, if so, how important is it?
• How self-contained the fix is - if it fixes a significant issue but also refactors a lot of code, it's probably worth thinking about what a less risky fix might look like
• Whether the fix is already on master - a change must be a backport of a change already merged onto master, unless the change simply does not make sense on master.

Rules to maintain multiple versions and exceptions will be added later.

The stable review team needs to balance the risk of any given patch with the value that it will provide to users of the stable branch. A large, risky patch for a major data corruption issue might make sense. As might a trivial fix for a fairly obscure error handling case.

Some types of changes are completely forbidden:

• New features
• Changes to the external APIs
• Changes to the notification definitions
• DB schema changes
• Incompatible config file changes

This excludes changes that include a version upgrade of an upstream component of OPNFV.

Support phases will be introduced at a later time

Each backported commit proposed to gerrit should be reviewed and +2ed by two Arno-stable-maint members before it is approved. Where a stable-maint member has backported a fix, a single other +2 is sufficient for approval.

If unsure about the technical details of a given fix, stable-maint members should consult with the appropriate developers from the affected projects for a more detailed technical review.

If unsure if a fix is appropriate for the stable branch, at this time the TSC will do the final decision.

Fixes for embargoed security issues receive special treatment. These should be reviewed in advance of disclosure by committers and stable-maint. At the time of coordinated public disclosure, the fix is proposed simultaneously to master and the stable branches and immediately approved.

I don't think we need that at the moment

Find better place for following text:

Existing committers are greatly encouraged to join the Arno-stable-maint team in order to help with reviewing backports, judging their appropriateness for the stable branch and approving them.