I agree -- supporting 3 ATS major versions is likely more work than it's worth. Traffic Ops core should continue to move towards being cache software agnostic.
Having said that, we have some logic today that generates config files differently, based on the ATS major version: https://github.com/apache/incubator-trafficcontrol/blob/a5d9ac705c97388bf18c09b32e8ef8434c243354/traffic_ops/app/lib/API/Configs/ApacheTrafficServer.pm#L2317 On Tue, Nov 21, 2017 at 7:52 PM, Jeremy Mitchell <[email protected]> wrote: > IMO, it's a lot to ask of a TC release to support multiple, inherently > different versions of ATS. We will end up with features or options that > pertains to one version of ATS but not another. By trying to support too > many versions of ATS, we complicate TC and if we ever want to implement any > type of self-service, we need to simplify TC rather than complicate it. > > Not sure how realistic this is but I'd like to see something like this: > > Examples: > > TC version 2.1 works with ATS 5/6 > TC version 2.2 works with ATS 5/6 > TC version 2.3 works with ATS 6/7 <-- sorry, if you are still sitting on > ATS 5 and want to move to TC 2.3, you need to upgrade ATS > > Jeremy > > On Tue, Nov 21, 2017 at 3:05 PM, Chris Lemmons <[email protected]> wrote: > > > As we continue the work of getting Traffic Control to work properly > > with ATS 7 and forward, we're having to re-work some of the ways we > > manipulate cache keys. The crux of the issue is that cacheurl was > > deprecated in 6 and has been removed in 7. Cacheurl was replaced with > > cachekey in 6. That unfortunately will make supporting both 5 and 7 a > > bit tricky. There are a few options for maintaining compatibility, but > > I thought I'd ask... would anyone find themselves sad if, at some > > point, Traffic Control stopped working with version 5 of ATS? And if > > not, what might be the best way to manage that? > > >
