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. >
