I could get behind a 4.0 milestone if that's just where we are. > ... who would determine what goes into a minor release...
That'd have to be done by voting for issues/PRs to include. But again, the timebox approach is fine IMO, but if there are outstanding bugs to be fixed or features that absolutely must be included in 4.0 (dropping Py2 support!) those can be easily tracked using a 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? Yeah that'd be the idea. But you're right, that almost certainly would slow us down so going back to Rawlin's suggestion, if we cut a new release today (I'd volunteer to manage if I could) then the milestone should only track things that *must* go into 4.0 and be back-ported into the candidate branch. That shouldn't be 40 things, it should probably be closer to 5. ________________________________________ From: Rawlin Peters <[email protected]> Sent: Monday, March 4, 2019 4:36 PM To: [email protected] Subject: Re: [EXTERNAL] Re: Release Milestones 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > Sent: Monday, March 4, 2019 2:21 PM > > To: [email protected] > > 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 > > <[email protected]> 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. > >
