<div dir="ltr">On 16 November 2014 at 17:34, Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Nov 12, 2014 at 6:44 AM, Leif Madsen <<a href="mailto:lmadsen@thinkingphones.com">lmadsen@thinkingphones.com</a>> wrote:<br>
> Would it also make sense to require new features be listed in the CHANGES<br>
> file for the point release? I don't want to add lots of work here, but when<br>
> you're developing against a major version release and new features are going<br>
> to be added, it would be great to have a go to spot (rather than browsing<br>
> all the ChangeLogs) for new features in case those deploying want to rebase<br>
> their work against a new point release in order to get a set of features.<br>
<br>
</span>Yup! We faced this with Asterisk 12 as well. To handle it for that version, we<br>
did the following:<br>
* CHANGES files were updated for each point release with the new features. As an<br>
  example, you can see the new features that went into 12.2 here:<br>
<br>
  <a href="http://svn.asterisk.org/svn/asterisk/tags/12.2.0/CHANGES" target="_blank">http://svn.asterisk.org/svn/asterisk/tags/12.2.0/CHANGES</a><br>
<br>
  At the same time, we don't really know which version people will be using when<br>
  they upgrade to the next major version. A feature may be introduced in 12.5.0,<br>
  and a person upgrading from 12.3.0 to 13.0.0 would not be aware of it. Since<br>
  all new features are also merged into trunk, new feature are listed as being<br>
  'new' in the first major version as well.<br>
* Release announcements for point releases also include an 'improvements' and<br>
  'new features' section, which correlate to the issue type in JIRA. The<br>
  announcement for 12.5.0 is a good example:<br>
<br>
  <a href="http://lists.digium.com/pipermail/asterisk-announce/2014-August/000552.html" target="_blank">http://lists.digium.com/pipermail/asterisk-announce/2014-August/000552.html</a><br>
<br>
  As well, the announcements made on <a href="http://asterisk.org" target="_blank">asterisk.org</a> also call out the different<br>
  types of issues included in the release:<br>
<br>
  <a href="http://www.asterisk.org/downloads/asterisk-news/asterisk-1250-now-available" target="_blank">http://www.asterisk.org/downloads/asterisk-news/asterisk-1250-now-available</a><br>
<br>
Beyond that, I'm not sure what else we should do - other than encourage people<br>
to write wiki pages for new features when they are developed.<br>
<span class=""><br></span></blockquote><div><br></div><div>I think this is perfectly reasonable. Thanks!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Last thing, regarding the old text block of "Asterisk 12 is Different" that<br>
> explains that changes are allowed towards the goals of that version; I think<br>
> it would be a good thing to have another similar block of text for Asterisk<br>
> 14. While the new policy is certainly more relaxed than the "no new<br>
> features", I also don't think it goes quite far enough for Standard releases<br>
> whereby larger architecture changes appeared to be allowed within the<br>
> Standard release, at least where required to support the lofty goals of<br>
> Asterisk 12. I understand Asterisk 14 goals haven't been finalized, but this<br>
> is something to keep in mind for this page in the future.<br>
<br>
</span>I had thought about having something like that on there, but I'm not quite sure<br>
how to phrase it in a fashion that is globally useful as a policy. The section<br>
earlier on the page does call out the differences between the two release types.<br>
Also, we do call out that certain features aren't appropriate for an LTS release<br>
on the new feature guidelines page:<br>
<br>
<a href="https://wiki.asterisk.org/wiki/display/AST/New+Feature+Guidelines" target="_blank">https://wiki.asterisk.org/wiki/display/AST/New+Feature+Guidelines</a><br>
<br>
The Roadmap, as well, calls out the goals for a particular version that were<br>
decided upon at AstriDevCon:<br>
<br>
<a href="https://wiki.asterisk.org/wiki/display/AST/Roadmap" target="_blank">https://wiki.asterisk.org/wiki/display/AST/Roadmap</a><br>
<br>
So the information may all be there, if on a few different pages. Maybe links<br>
to the appropriate pages would be sufficient</blockquote><div><br></div><div>Perhaps? I'm not exactly sure how to phrase it either. I suppose this was the general consensus at AstriDevCon, but I wonder how we go about making it a little more clear.<br><br></div><div>What is there now I think is sufficient, and those working on the project every day have a pretty good idea around what is acceptable.<br><br></div><div>Thanks!<br>Leif. <br></div></div></div></div>