As you've noticed, it's been a while and we still don't have a 4.x branch cut. In short, we wanted to tie up some things in regards to API versioning and make sure that it gets included in 4.x. I talked to Rawlin this morning and I am hopeful that we will be ready to create the new release branch by early next week.
Thanks, Dave On Tue, Oct 29, 2019 at 9:10 AM Dave Neuman <[email protected]> wrote: > Hey All, > Good news, Rawlin has volunteer to be our 4.x release manager! Thank you > Rawlin! > > I am going to work with Rawlin to get a 4.x branch created early next > week. Once this branch is created, all changes that we want to include in > 4.0 will need to have a backport PR opened against the 4.x branch. I > didn't get too much feedback on critical features that are outstanding for > 4.0, so we may look at creating a release candidate before the end of > November. > Ultimately, the plan is to get 4.0 out and then try to get on a 4-6 week > cadence with minor releases. I will send another email on how I would like > this to look. > > Please let me know if you have any strong objections to the plan for 4.0, > otherwise Rawlin and I will continue to move forward. > > Thanks, > Dave > > PS -- WE STILL NEED ONE MORE VOTE ON 3.1, PLEASE, PLEASE HELP US! > > On Wed, Oct 23, 2019 at 1:34 PM David Neuman <[email protected]> > wrote: > >> Hey All, >> It's been long enough and I think it's time we get serious about our 4.0 >> release. Our last Major release was 3.0 which was released in March. We >> have a 3.1 release candidate out now (GO VOTE!) but that release contains >> just a few fixes on top of 3.0. There have been several big features added >> since 3.0, you can get an idea from the changelog[1], and it's time that we >> get these into a release. >> >> We never really committed to a feature based release scope for our next >> release, so I would like to make a time based release scope. I would like >> to see if we can get all changes that we want in 4.0 merged before the end >> of November. This gives everyone almost 6 weeks to finish up anything in >> flight, work on getting PRs merged, and to fix any outstanding issues. If >> you feel like this timeline is too aggressive please speak up so we can >> discuss. I would like us to be able to have a testable release candidate >> out by the middle of December so that we can use the holiday time (when >> most folks are in moratorium) to do testing and hopefully get a release out >> in Q1. >> >> Looking forward, I would like to get us on a more frequent cadence with >> our releases, preferably with minor releases every 4-6 weeks. I will save >> this idea for another thread as to not muddy up our focus on getting a 4.x >> branch cut and a 4.0 release candidate prepared. >> >> Please let me know if you have any features our outstanding work that you >> would like to see included in 4.0 that you will not have completed by Nov >> 30. Please also let me know if you know of any CRITICAL outstanding issues >> that need to be addressed before our next release. >> >> In the meantime I will work on finding a Release Manager and working with >> them to get ready to cut the 4.x branch. >> >> >> Thanks, >> Dave >> >> [1] https://github.com/apache/trafficcontrol/blob/master/CHANGELOG.md >> >>
