For anyone interested in what the resulting code would look like for my TO API minor versioning proposal, I prototyped a new `foos` endpoint that supports several different minor versions (as if the endpoint had seen minor changes across several different releases of Traffic Control -- not that we would ever add a new endpoint supporting multiple minor versions at once):
https://github.com/apache/trafficcontrol/pull/3538 My plan is to refactor the current Delivery Services API implementation into something very close to that in order to simplify the handling of minor versioning. After delivery services, I might tackle the one or two other endpoints that also do minor versioning in order to be consistent with this approach. - Rawlin On Tue, Apr 30, 2019 at 7:55 PM Jeremy Mitchell <[email protected]> wrote: > > +1 > > On Tue, Apr 30, 2019 at 1:00 PM Dave Neuman <[email protected]> wrote: > > > +1 to Rawlin's latest proposal. > > If we can get consensus then let's close the PRs for previous solutions and > > move forward with this one. > > > > Thanks, > > Dave > > > > > > On Fri, Apr 26, 2019 at 3:58 PM Rawlin Peters <[email protected]> > > wrote: > > > > > On Wed, Apr 24, 2019 at 10:53 AM Robert Butts <[email protected]> wrote: > > > > We might even be able to do a little better than that, and only have > > one > > > > handler, no separate versions in the routes/handlers. So, the route > > would > > > > look something like: > > > > > > > > func Update(w http.ResponseWriter, r *http.Request) { > > > > inf, userErr, sysErr, errCode := api.NewInfo(r, nil, nil) > > > > dsVer := tc.NewDeliveryService(inf.Version) > > > > api.Parse(r.Body, inf.Tx.Tx, &ds) > > > > ds := dsVer.Upgrade(inf.Tx.Tx) > > > > > > I think that could be doable, but I think that would imply having to > > > go update every minor-versioned-struct's `Upgrade` method whenever a > > > new minor version is added. That is, each minor-versioned-struct would > > > need to maintain instructions on how to upgrade to the latest version > > > of the struct. That maintenance cost would increase with every added > > > minor version, which is why I was thinking it should really just chain > > > together, upgrading/downgrading the request. That way when adding a > > > new minor version, you'd only be on the hook for writing instructions > > > to upgrade from the previous minor version to the latest minor > > > version, without having to touch any of the other minor versions. The > > > less we have to touch the previous minor versions, the easier it would > > > be for us to support _all_ minor versions, which means TO clients > > > would last longer without needing to upgrade (as opposed to just > > > supporting the "latest" minor version of the API and dropping all > > > other minor versions from one major TC release to the next, like > > > Jonathan has described). > > > > > > A downside to chaining would be that each minor version upgrade you > > > have to do is an extra DB query, so if a client is on the oldest > > > possible minor version, they could be taking a decent hit on added > > > latency. But, if it becomes a problem for the client, they would have > > > added incentive to upgrade to the latest minor version. If we drop > > > support for all but the latest minor version of the API when we > > > upgrade to the next major TC version, I think that would mean we'd > > > really only be supporting two minor versions at any point in time, so > > > maybe doing it the way you've proposed in the code snippet above would > > > be the same amount of work at that point anyways. > > > > > > - Rawlin > > > > >
