Re: [asterisk-dev] Process change proposal: allowing new features and improvements into release branches
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
Re: [asterisk-dev] Process change proposal: allowing new features and improvements into release branches
On Wed, Nov 12, 2014 at 6:44 AM, Leif Madsen lmad...@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 -- _ -- 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
Re: [asterisk-dev] Process change proposal: allowing new features and improvements into release branches
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.
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.
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.
Thanks to everyone involved in making Asterisk awesome.
Leif.
On 10 November 2014 17:57, Matthew Jordan mjor...@digium.com wrote:
At AstriDevCon, we spent a good amount of time discussing whether or
not we should allow new features or improvements to be made in release
branches. As I summarized previously [1]:
{quote}
Draft a policy for allowing improvements in release branches.
The Asterisk project today does not exist in the same world - and is
not the same project - as when the no new feature in release
branches policy was first employed. We have a rigorous peer review
process, multiple test suites, continuous integration infrastructure,
and more to help prevent regressions or other problems from occurring.
In addition, the world today is also moving faster, and we'd like to
make sure that Asterisk maintains pace with changes in the industry.
At the same time, we have to ensure that release branches are stable
and that a user can upgrade within a release branch and not worry
about behavioural changes. We feel we can strike that balance with the
right policy.
{quote}
Before everyone rejoices/panics too much, there are restrictions on
proposing a new feature or improvement to a release branch:
(1) Any new feature proposed for an existing release branch must have
suitable test coverage using either the Asterisk Test Suite, the
Asterisk Unit Test Framework, or both.
(2) The new feature or improvement must be backwards compatible with
the previous releases in those major versions. That is, users
upgrading from one point release to the next should not be aware of
any new feature or improvement unless they want to use said feature.
Some things that should not be changed naturally follow from this:
(2a) APIs that follow semantic versioning should not receive a major
version increase.
(2b) Configuration and database schemas can be added to or updated,
but users should not be required to update their configuration or
databases.
(3) Any new features or improvements must be included in the first
release candidate of a new version. First release candidate
announcements must be made to the asterisk-users mailing lists, with
at least a week of testing time allowed. If a new feature or
improvement is deemed to cause an inappropriate burden on end-users,
it must be removed from the release.
Hopefully, this strikes the right balance of allowing the project to
keep pace with end user's needs, without introducing substantial risk
into release branches.
The full text of the
Re: [asterisk-dev] Process change proposal: allowing new features and improvements into release branches
+1
This sounds more than reasonable to me.
Sent from my iPhone
On Nov 10, 2014, at 5:57 PM, Matthew Jordan mjor...@digium.com wrote:
At AstriDevCon, we spent a good amount of time discussing whether or
not we should allow new features or improvements to be made in release
branches. As I summarized previously [1]:
{quote}
Draft a policy for allowing improvements in release branches.
The Asterisk project today does not exist in the same world - and is
not the same project - as when the no new feature in release
branches policy was first employed. We have a rigorous peer review
process, multiple test suites, continuous integration infrastructure,
and more to help prevent regressions or other problems from occurring.
In addition, the world today is also moving faster, and we'd like to
make sure that Asterisk maintains pace with changes in the industry.
At the same time, we have to ensure that release branches are stable
and that a user can upgrade within a release branch and not worry
about behavioural changes. We feel we can strike that balance with the
right policy.
{quote}
Before everyone rejoices/panics too much, there are restrictions on
proposing a new feature or improvement to a release branch:
(1) Any new feature proposed for an existing release branch must have
suitable test coverage using either the Asterisk Test Suite, the
Asterisk Unit Test Framework, or both.
(2) The new feature or improvement must be backwards compatible with
the previous releases in those major versions. That is, users
upgrading from one point release to the next should not be aware of
any new feature or improvement unless they want to use said feature.
Some things that should not be changed naturally follow from this:
(2a) APIs that follow semantic versioning should not receive a major
version increase.
(2b) Configuration and database schemas can be added to or updated,
but users should not be required to update their configuration or
databases.
(3) Any new features or improvements must be included in the first
release candidate of a new version. First release candidate
announcements must be made to the asterisk-users mailing lists, with
at least a week of testing time allowed. If a new feature or
improvement is deemed to cause an inappropriate burden on end-users,
it must be removed from the release.
Hopefully, this strikes the right balance of allowing the project to
keep pace with end user's needs, without introducing substantial risk
into release branches.
The full text of the proposed process changes has been made to the
Software Configuration Management Policies page on the Asterisk wiki
[2], with the proposed text put side-by-side with the existing text
for comparison. If we reach a consensus that this is a good thing,
I'll remove the old text.
Thoughts? Concerns?
[1] http://lists.digium.com/pipermail/asterisk-dev/2014-October/071076.html
[2]
https://wiki.asterisk.org/wiki/display/AST/Software+Configuration+Management+Policies
--
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
--
_
-- 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
--
_
-- 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
[asterisk-dev] Process change proposal: allowing new features and improvements into release branches
At AstriDevCon, we spent a good amount of time discussing whether or
not we should allow new features or improvements to be made in release
branches. As I summarized previously [1]:
{quote}
Draft a policy for allowing improvements in release branches.
The Asterisk project today does not exist in the same world - and is
not the same project - as when the no new feature in release
branches policy was first employed. We have a rigorous peer review
process, multiple test suites, continuous integration infrastructure,
and more to help prevent regressions or other problems from occurring.
In addition, the world today is also moving faster, and we'd like to
make sure that Asterisk maintains pace with changes in the industry.
At the same time, we have to ensure that release branches are stable
and that a user can upgrade within a release branch and not worry
about behavioural changes. We feel we can strike that balance with the
right policy.
{quote}
Before everyone rejoices/panics too much, there are restrictions on
proposing a new feature or improvement to a release branch:
(1) Any new feature proposed for an existing release branch must have
suitable test coverage using either the Asterisk Test Suite, the
Asterisk Unit Test Framework, or both.
(2) The new feature or improvement must be backwards compatible with
the previous releases in those major versions. That is, users
upgrading from one point release to the next should not be aware of
any new feature or improvement unless they want to use said feature.
Some things that should not be changed naturally follow from this:
(2a) APIs that follow semantic versioning should not receive a major
version increase.
(2b) Configuration and database schemas can be added to or updated,
but users should not be required to update their configuration or
databases.
(3) Any new features or improvements must be included in the first
release candidate of a new version. First release candidate
announcements must be made to the asterisk-users mailing lists, with
at least a week of testing time allowed. If a new feature or
improvement is deemed to cause an inappropriate burden on end-users,
it must be removed from the release.
Hopefully, this strikes the right balance of allowing the project to
keep pace with end user's needs, without introducing substantial risk
into release branches.
The full text of the proposed process changes has been made to the
Software Configuration Management Policies page on the Asterisk wiki
[2], with the proposed text put side-by-side with the existing text
for comparison. If we reach a consensus that this is a good thing,
I'll remove the old text.
Thoughts? Concerns?
[1] http://lists.digium.com/pipermail/asterisk-dev/2014-October/071076.html
[2]
https://wiki.asterisk.org/wiki/display/AST/Software+Configuration+Management+Policies
--
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
--
_
-- 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
