rawlinp commented on issue #4534: Fix ORT atstccfg to allow using new features in the latest Traffic Ops URL: https://github.com/apache/trafficcontrol/pull/4534#issuecomment-603459860 Ok, I agree that tight coupling is bad, but this seems like something that should be well-communicated with the entire project for everyone to get on board with if our goal is to follow this pattern for every component. This seems more like a backwards-compatibility issue than a coupling issue. API clients will always be coupled to the API, and if a client is coupled to two versions of the same API, doesn't that make it even more tightly coupled to that API? It seems like the trade-off being made is really getting better backwards compatibility with TO at the cost of tighter coupling and increased complexity of components. Maybe we're ok with that, but maybe we're ok with always upgrading TO first? The order doesn't necessarily need to be TO -> TM -> TR -> ORT for example, it could just be "TO first". If we need to fully roll back TO after we've already upgraded most of the other components in the chain, wouldn't we be risking more serious data loss if we rolled back TO at that point rather than hotfixing it and rolling forwards?
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
