[prev in list] [next in list] [prev in thread] [next in thread]
List: asterisk-dev
Subject: Re: [asterisk-dev] Process change proposal: allowing new features and improvements into release bran
From: Leif Madsen <lmadsen () thinkingphones ! com>
Date: 2014-11-27 14:11:52
Message-ID: CAD8WRm66WMxzQ9C-7cY1+BSdfY1Y8duz2X1aW48AvC+6kCAN=Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On 16 November 2014 at 17:34, Matthew Jordan <mjordan@digium.com> wrote:
> On Wed, Nov 12, 2014 at 6:44 AM, Leif Madsen <lmadsen@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.
[Attachment #5 (text/html)]
<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>
--
_____________________________________________________________________
-- 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic