+1 This sounds more than reasonable to me.
Sent from my iPhone > On Nov 10, 2014, at 5:57 PM, Matthew Jordan <mjor...@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 -- _____________________________________________________________________ -- 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