[asterisk-dev] Proposal for New Major Version Process Change

[Kevin Harwell]

+1

I would also would approve of other potential changes to releases and the
release process but will save that for another time :-D

On Wed, Jul 8, 2020 at 7:21 AM Joshua C. Colp <jcolp at sangoma.com> wrote:

> Greetings all,
>
> I've given this some thought in the past and thought with the impending
> branching of Asterisk 18 I'd get some input on a change to the process. The
> new major version process has evolved over time but hasn't really been
> changed lately. Let's look at what it is like in practice today:
>
> On July 15th under current process both the 18 branch and 18.0 branches
> will be cut. The 18 branch will continue to receive all bug fixes, but the
> 18.0 branch will only receive changes as a result of issues found through
> testing 18.0 or through big fixes to new functionality in it. This means
> that when 18.0.0 is actually released it is generally a few months behind.
> In the past this was to give it time to stabilize as it were. This presents
> the following issues:
>
> 1. It leaves a confusing area for developers where we have to ask "should
> this go into 18.0?"
> 2. It confuses users because if they upgrade to 18.0.0 then it is likely
> the other current releases have bug fixes they don't have, which has caused
> issues for users in the past.
>
> I don't think this is the best situation for either.
>
> I'd like to propose that instead of cutting the 18.0 branch on July 15th
> we simply cut the 18 branch, and that it continues to receive all bug
> fixes. Approximately a month before a target release of 18.0.0 we create
> the first release candidate, 18.0.0-rc1. At this time we also create
> release candidates of the other branches. All release candidates will then
> be left available for a prolonged period of time to give people ample time
> to test. On the release date all will be released, ensuring that all
> branches including 18 have the same set of bug fixes as appropriate to
> their version.
>
> This removes the confusion for developers over whether to include a fix,
> since the 18.0 branch won't exist until rc1 at which point normal cherry
> pick rules apply. This also eliminates the confusion experienced by users
> since all releases will be on the same page at the same time at release.
>
> What do people think? Do we believe that a month out is ample enough? The
> 18 branch itself will exist, so that can be used for early testing (and
> likely will be). If a month isn't enough it could be moved out further.
> Really I think thanks to the testing that happens and the code review I
> don't think we need as long of a stabilization period as has been needed in
> the past, so this helps shrink it.
>
> Cheers,
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.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



-- 
Kevin Harwell
Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20200708/37fee4e6/attachment-0001.html>