I think a milestone need to be created for 3.0.1 for bug fixes. I believe we have enough bugs to fix that should be ported back to 3.0. At least we can build from 3.0.x with latest fixes. We ended up in production with 4-5 different build number for numerous components.
I know users won't be able to install Traffic Ops 3.0 for example on a Centos 7.6 server (which was released in December). This stuff should be ported back and documented in the change log. Steve On Wed, Mar 6, 2019 at 4:38 PM Jeremy Mitchell <[email protected]> wrote: > I do think we should settle on some "minimum quality standards" for a > release. I.e. No more than > > - 0 critical bugs ( > > https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+label%3Abug+label%3Acritical > ) > - 0 blocker bugs ( > > https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+label%3Abug+label%3Ablocker > ) > - X major bugs ( > > https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+label%3Amajor+label%3Abug > ) > > although those labels are very subjective. one person's "critical" is > another person's "trivial". > > if we can agree on the "minimum quality standards", it should be added to > the release process ( > https://cwiki.apache.org/confluence/display/TC/Release+Management+Process) > imo and be enforced by the release manager. however, i'm not sure how you > enforce it... > > jeremy > > > > On Tue, Mar 5, 2019 at 11:39 AM Fieck, Brennan <[email protected]> > wrote: > > > 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. > > > > > > >
