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.
