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

Wed Nov 12 06:44:22 CST 2014

Matt and Community,

This looks great to me. I've tweaked the wiki page a little bit to better
reflect the branch merging since 1.8 is now EOL. Otherwise, I think this
meets a very nice balance between "allowing features in to keep pace with
the industry" and anarchy.

I look forward to next AstriCon to see what features ended up coming from
this earlier than the next LTS (I understand it could be in Standard as
well, but that is a little more wild west than perhaps people might be
comfortable with).

One of the things is that new features must be in new feature releases, and
that some sort of announcement needs to be made showing that a new feature
was added. I assume this would happen in the ChangeLog and the announcement
release that goes out for all Asterisk releases. If there isn't already
some sort of flag or naming scheme that indicates new features, perhaps
there should be so that it is easier to parse out for the announcements.
Perhaps some sort of naming tag in the commit message like [FEATURE] or
something.

Would it also make sense to require new features be listed in the CHANGES
file for the point release? I don't want to add lots of work here, but when
you're developing against a major version release and new features are
going to be added, it would be great to have a go to spot (rather than
browsing all the ChangeLogs) for new features in case those deploying want
to rebase their work against a new point release in order to get a set of
features.

Last thing, regarding the old text block of "Asterisk 12 is Different" that
explains that changes are allowed towards the goals of that version; I
think it would be a good thing to have another similar block of text for
Asterisk 14. While the new policy is certainly more relaxed than the "no
new features", I also don't think it goes quite far enough for Standard
releases whereby larger architecture changes appeared to be allowed within
the Standard release, at least where required to support the lofty goals of
Asterisk 12. I understand Asterisk 14 goals haven't been finalized, but
this is something to keep in mind for this page in the future.

Perhaps you might want to add a placeholder for that type of thing, or
generate a more generalized block of text that says Standard releases may
have changes that appear more aggressive than the feature release policy
dictates, but must be towards the goals set out for the Standard release
during AstriDevCon.

Thanks to everyone involved in making Asterisk awesome.

Leif.

On 10 November 2014 17:57, 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
>

-- 
Leif Madsen
CoreUC Lead Systems Engineer
p: +1-613-800-7610
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141112/1986f02c/attachment-0001.html>