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

[Leif Madsen]

On 16 November 2014 at 17:34, Matthew Jordan <mjordan at digium.com> wrote:

> On Wed, Nov 12, 2014 at 6:44 AM, Leif Madsen <lmadsen at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141127/f83bf8c5/attachment-0001.html>