[asterisk-dev] Process change proposal: allowing new features and improvements into release branches

[Matthew Jordan]

At AstriDevCon, we spent a good amount of time discussing whether or
not we should allow new features or improvements to be made in release
branches. As I summarized previously [1]:

{quote}
Draft a policy for allowing improvements in release branches.

The Asterisk project today does not exist in the same world - and is
not the same project - as when the "no new feature in release
branches" policy was first employed. We have a rigorous peer review
process, multiple test suites, continuous integration infrastructure,
and more to help prevent regressions or other problems from occurring.
In addition, the world today is also moving faster, and we'd like to
make sure that Asterisk maintains pace with changes in the industry.
At the same time, we have to ensure that release branches are stable
and that a user can upgrade within a release branch and not worry
about behavioural changes. We feel we can strike that balance with the
right policy.
{quote}

Before everyone rejoices/panics too much, there are restrictions on
proposing a new feature or improvement to a release branch:
(1) Any new feature proposed for an existing release branch must have
suitable test coverage using either the Asterisk Test Suite, the
Asterisk Unit Test Framework, or both.
(2) The new feature or improvement must be backwards compatible with
the previous releases in those major versions. That is, users
upgrading from one point release to the next should not be aware of
any new feature or improvement unless they want to use said feature.
Some things that should not be changed naturally follow from this:
(2a) APIs that follow semantic versioning should not receive a major
version increase.
(2b) Configuration and database schemas can be added to or updated,
but users should not be required to update their configuration or
databases.
(3) Any new features or improvements must be included in the first
release candidate of a new version. First release candidate
announcements must be made to the asterisk-users mailing lists, with
at least a week of testing time allowed. If a new feature or
improvement is deemed to cause an inappropriate burden on end-users,
it must be removed from the release.

Hopefully, this strikes the right balance of allowing the project to
keep pace with end user's needs, without introducing substantial risk
into release branches.

The full text of the proposed process changes has been made to the
Software Configuration Management Policies page on the Asterisk wiki
[2], with the proposed text put side-by-side with the existing text
for comparison. If we reach a consensus that this is a "good thing",
I'll remove the old text.

Thoughts? Concerns?

[1] http://lists.digium.com/pipermail/asterisk-dev/2014-October/071076.html
[2] https://wiki.asterisk.org/wiki/display/AST/Software+Configuration+Management+Policies

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org