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
