On 16 November 2014 at 17:34, Matthew Jordan <mjor...@digium.com> wrote:
> On Wed, Nov 12, 2014 at 6:44 AM, Leif Madsen <lmad...@thinkingphones.com> > wrote: > > 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. > > Yup! We faced this with Asterisk 12 as well. To handle it for that > version, we > did the following: > * CHANGES files were updated for each point release with the new features. > As an > example, you can see the new features that went into 12.2 here: > > http://svn.asterisk.org/svn/asterisk/tags/12.2.0/CHANGES > > At the same time, we don't really know which version people will be > using when > they upgrade to the next major version. A feature may be introduced in > 12.5.0, > and a person upgrading from 12.3.0 to 13.0.0 would not be aware of it. > Since > all new features are also merged into trunk, new feature are listed as > being > 'new' in the first major version as well. > * Release announcements for point releases also include an 'improvements' > and > 'new features' section, which correlate to the issue type in JIRA. The > announcement for 12.5.0 is a good example: > > > http://lists.digium.com/pipermail/asterisk-announce/2014-August/000552.html > > As well, the announcements made on asterisk.org also call out the > different > types of issues included in the release: > > > http://www.asterisk.org/downloads/asterisk-news/asterisk-1250-now-available > > Beyond that, I'm not sure what else we should do - other than encourage > people > to write wiki pages for new features when they are developed. > > I think this is perfectly reasonable. Thanks! > > 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. > > I had thought about having something like that on there, but I'm not quite > sure > how to phrase it in a fashion that is globally useful as a policy. The > section > earlier on the page does call out the differences between the two release > types. > Also, we do call out that certain features aren't appropriate for an LTS > release > on the new feature guidelines page: > > https://wiki.asterisk.org/wiki/display/AST/New+Feature+Guidelines > > The Roadmap, as well, calls out the goals for a particular version that > were > decided upon at AstriDevCon: > > https://wiki.asterisk.org/wiki/display/AST/Roadmap > > So the information may all be there, if on a few different pages. Maybe > links > to the appropriate pages would be sufficient 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. 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. Thanks! Leif.
-- _____________________________________________________________________ -- 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