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

[BJ Weschke]

+1

This sounds more than reasonable to me.

Sent from my iPhone

> On Nov 10, 2014, at 5:57 PM, Matthew Jordan <mjordan at digium.com> wrote:
> 
> 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
> 
> -- 
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev