Yeah, I agree with not doing a backport release for 3.1. I think the 3.0.x branch was cut in early 09/18, which means master has advanced nearly 6 months ahead now. I think unless there is a major bugfix required for a 3.0.1 release, our next release should probably be 4.0. That said, I don't know of anything that would prevent us from cutting the 4.0.x branch off master right now, and given the cadence of the last 3 major releases (3.0, 2.2, and 2.1) I think it would take about 4-6 months to get the release out the door once the release branch is cut off master. So, I don't think it will take a full year for the next release.
Are there any committers out there itching to be the next release manager? - Rawlin On Mon, Mar 4, 2019 at 3:39 PM Jeremy Mitchell <mitchell...@gmail.com> wrote: > > I believe master is waaaaay ahead of the 3.0.x branch so doing a cherry > pick (backport) of a feature for 3.1.0 might not be a safe operation. plus, > we don't typically do minor releases (not that we can't but who would > determine what goes into a minor release). > > Because we don't have dedicated resources to properly plan and scope > releases, we've always just followed the time-box approach. i.e. every X > months, cut a release branch from master. at one point, i think we agreed > to 2 or 3 major releases a year. IMO we should commit to 2 major releases a > year and on Jan 1 and July 1 of every year cut a release branch from > master. whatever is in master at that point makes the release. > > milestones seem like a great idea and we tried them in the past but at the > end of the day who is responsible for doing the work in the milestone. if > we create a 4.0 milestone and put 40 issues in it, does that mean we don't > cut the 4.0 branch until those 40 things are done? we might actually slow > our cadence down if we do that. > > jeremy > > On Mon, Mar 4, 2019 at 2:50 PM Fieck, Brennan <brennan_fi...@comcast.com> > wrote: > > > There's a v1.5 API for doing consistent hashing using path regexes for > > HTTP-routed delivery services, there have been Go client updates that > > weren't in 3.0.0RC6 that would be required to get CiaB running on that > > branch, and there have been numerous documentation updates and > > bug fixes. At our current release cadence, these things will not reach > > an official release for another year or so. I think we could easily come up > > with a list of changes to include in 3.0.1 and 3.1.0 releases, if not any > > planned future changes. > > ________________________________________ > > From: Rawlin Peters <rawlin.pet...@gmail.com> > > Sent: Monday, March 4, 2019 2:21 PM > > To: dev@trafficcontrol.apache.org > > Subject: [EXTERNAL] Re: Release Milestones > > > > I think master is mostly slated for 4.0 at this point, so any 3.1 > > and/or 3.0.1 releases would probably have to be backports unless we're > > willing to consider 3.1 a "next major release" for things like > > removing the legacy Traffic Ops Perl UI. I think that was at least one > > thing that was basically committed to 4.0, but there might be other > > stuff too. > > > > That said, it's hard to justify doing a release without considering > > what we'd like to get into the potential release. For example, is > > there a major bugfix that warrants a 3.0.1 and/or a new feature in > > master that should be backported into a 3.1 release rather than > > waiting until we cut master into 4.0? > > > > - Rawlin > > > > On Mon, Mar 4, 2019 at 11:26 AM Fieck, Brennan > > <brennan_fi...@comcast.com> wrote: > > > > > > To perhaps help us push out releases in a more timely fashion, maybe we > > should start making release Milestones? > > > We've had them in the past: > > https://github.com/apache/trafficcontrol/milestones I don't think > > deciding on what we > > > > > > want in 4.0.0 is realistic right now, but we could certainly start > > planning for 3.0.1 and even 3.1.0. Adding issues to fix > > > > > > or Pull Requests to include would probably be a voting process (a > > cursory reading of the ASF release candidate > > > > > > process suggests that the votes for merely planning a release need not > > be "binding", though I could very well be > > > > > > wrong about that). Honestly, for a patch version we should probably only > > look at things that are actually done, > > > > > > whereas for a minor version release we'd want to plan on including fixes > > for extant problems and including functionality > > > > > > that may not be written today. > > > > > > > > > Making sure everything that goes into a release is tracked by a > > milestone as progress is made will also simplify > > > > > > checking the changelog for everything that should be there/maybe even > > generating the changelog from the milestone. > > > > > > > > > I don't have the authority to create milestones, which suggests that > > even doing that requires a vote from the community > > > > > > before any committers feel obligated to do anything. I'm +1 on creating > > milestones for 3.1.0 and 3.0.1, and if and > > > > > > when voting on those commences I have some candidates for inclusion in > > each to propose. > >
