any more thoughts here? otherwise, looks like our next version will be 7.0 (api 4.x stablization and api 2.x removal tbd). this means we will need a new volunteer for release manager. any volunteers?
On Tue, Feb 8, 2022 at 4:05 PM Rawlin Peters <raw...@apache.org> wrote: > We don't really support upgrading more than one major version at a > time anyways (esp. due to things like squashing the DB migrations), so > you generally need to upgrade only one major version at a time (e.g. > 4.x -> 5.x -> 6.x -> 7.x). > > - Rawlin > > On Tue, Feb 8, 2022 at 3:47 PM Gray, Jonathan > <jonathan_g...@comcast.com.invalid> wrote: > > > > Removing API 2.x will mean that there is no migration path from ATC 4.x > to ATC 7 without jumping through ATC 5||6 to get to API 3.0+. This might > be ok, but just a reminder. Specifically the existing ansible code still > relies on API 2.x as well. > > > > Jonathan G > > > > > > From: Rawlin Peters <raw...@apache.org> > > Date: Tuesday, February 8, 2022 at 3:32 PM > > To: dev@trafficcontrol.apache.org <dev@trafficcontrol.apache.org> > > Subject: [EXTERNAL] Re: TC Q2 release (6.2 or 7.0?) > > If we decide that we're going to declare TO API 4.x stable as part of > > ATC 7.0 on April 1, we're effectively setting a deadline for > > work-in-progress (Layered Profiles) upon which the release hinges. > > Ideally, we would wait until the Layered Profiles feature is > > implemented in TO API 4.0 before we consider stabilizing TO API 4.0. > > We don't want to delay the release because a new feature isn't ready > > yet. > > > > That said, I don't see a problem with removing API 2.x and Riak > > support (as well as any of those other "major" things) and calling it > > ATC 7.0. > > > > - Rawlin > > > > On Tue, Feb 8, 2022 at 12:33 PM Jeremy Mitchell <mitchell...@apache.org> > wrote: > > > > > > In today's TC working group, we discussed our next official release > slated > > > for Q2 (April 1). We have 2 options: > > > > > > 1. TC 6.2.0 > > > 2. TC 7.0.0 > > > > > > ^^ note: this doesn't include any patch releases we may need prior to > April > > > 1. > > > > > > We felt option #2 was probably the better option so we could: > > > > > > - stabilize API 4.x which is currently "unstable" > > > - deprecate API 3.x which is currently considered "stable" > > > - remove API 2.x which is currently deprecated > > > - optionally (if needed) add API 5.x as "unstable" to allow more > breaking > > > API changes if needed > > > > > > In addition, we could potentially remove RIAK support > > > < > https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/issues/6546__;!!CQl3mcHX2A!XgJ4rHATX7p8UEz7mVduk1HnteBDNBxQEqUFIHrEMRI4nE5CjpvAiRCK-UuVbZ2wWxcU$ > >, introduce a > > > new/replacement auth mechanism (i.e. JWT) and upgrade TR to Java 17 as > well > > > as other "major" things. > > > > > > Or, we could do none/subset of that and plan on a 6.2 for April. > > > > > > Thoughts? >
