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

[Matthew Jordan]

On Wed, Nov 12, 2014 at 6:44 AM, Leif Madsen <lmadsen at thinkingphones.com> wrote:
> 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.

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.

> 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 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.
>

-- 
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