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.
