On Wed, Jul 8, 2020 at 6:21 AM Joshua C. Colp <jc...@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. > Agreed. > > 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. > Sounds like a good plan. > > 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. > +1 > > 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 -- George Joseph Asterisk Software Developer direct/fax +1 256 428 6012 Check us out at www.sangoma.com and www.asterisk.org [image: image.png]
-- _____________________________________________________________________ -- 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