<div dir="ltr"><div><div><div><div><div>Matt and Community,<br><br>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.<br><br></div>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).<br><br></div>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.<br><br></div>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.<br><br></div>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.<br><br>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.<br><br></div>Thanks to everyone involved in making Asterisk awesome.<br><br>Leif.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 November 2014 17:57, Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">At AstriDevCon, we spent a good amount of time discussing whether or<br>
not we should allow new features or improvements to be made in release<br>
branches. As I summarized previously [1]:<br>
<br>
{quote}<br>
Draft a policy for allowing improvements in release branches.<br>
<br>
The Asterisk project today does not exist in the same world - and is<br>
not the same project - as when the "no new feature in release<br>
branches" policy was first employed. We have a rigorous peer review<br>
process, multiple test suites, continuous integration infrastructure,<br>
and more to help prevent regressions or other problems from occurring.<br>
In addition, the world today is also moving faster, and we'd like to<br>
make sure that Asterisk maintains pace with changes in the industry.<br>
At the same time, we have to ensure that release branches are stable<br>
and that a user can upgrade within a release branch and not worry<br>
about behavioural changes. We feel we can strike that balance with the<br>
right policy.<br>
{quote}<br>
<br>
Before everyone rejoices/panics too much, there are restrictions on<br>
proposing a new feature or improvement to a release branch:<br>
(1) Any new feature proposed for an existing release branch must have<br>
suitable test coverage using either the Asterisk Test Suite, the<br>
Asterisk Unit Test Framework, or both.<br>
(2) The new feature or improvement must be backwards compatible with<br>
the previous releases in those major versions. That is, users<br>
upgrading from one point release to the next should not be aware of<br>
any new feature or improvement unless they want to use said feature.<br>
Some things that should not be changed naturally follow from this:<br>
(2a) APIs that follow semantic versioning should not receive a major<br>
version increase.<br>
(2b) Configuration and database schemas can be added to or updated,<br>
but users should not be required to update their configuration or<br>
databases.<br>
(3) Any new features or improvements must be included in the first<br>
release candidate of a new version. First release candidate<br>
announcements must be made to the asterisk-users mailing lists, with<br>
at least a week of testing time allowed. If a new feature or<br>
improvement is deemed to cause an inappropriate burden on end-users,<br>
it must be removed from the release.<br>
<br>
Hopefully, this strikes the right balance of allowing the project to<br>
keep pace with end user's needs, without introducing substantial risk<br>
into release branches.<br>
<br>
The full text of the proposed process changes has been made to the<br>
Software Configuration Management Policies page on the Asterisk wiki<br>
[2], with the proposed text put side-by-side with the existing text<br>
for comparison. If we reach a consensus that this is a "good thing",<br>
I'll remove the old text.<br>
<br>
Thoughts? Concerns?<br>
<br>
[1] <a href="http://lists.digium.com/pipermail/asterisk-dev/2014-October/071076.html" target="_blank">http://lists.digium.com/pipermail/asterisk-dev/2014-October/071076.html</a><br>
[2] <a href="https://wiki.asterisk.org/wiki/display/AST/Software+Configuration+Management+Policies" target="_blank">https://wiki.asterisk.org/wiki/display/AST/Software+Configuration+Management+Policies</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Matthew Jordan<br>
Digium, Inc. | Engineering Manager<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a><br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div>Leif Madsen<br>CoreUC Lead Systems Engineer<br></div>p: +1-613-800-7610<br><div><br></div></div></div>
</div>