Re-think use of "Backwards Compatibility" and replace with something more appropriate
adityasaky opened this issue · comments
@trishankatdatadog noted in #13 (comment) that the term "backwards compatible" could be misleading. "Legacy" and "Deprecated" were suggested as alternatives, and @MarkLodato said this replacement could occur in a standalone PR.
Not to mention that we should more seriously think about backwards-compatibility in the first place. As it is, the spec is not at all backwards-compatible with older clients who may not have the luxury to update, and older repositories who may not have the luxury to maintain two different, incompatible versions of metadata.
Hi Trishank. You bring up a very good point. After further thought, I don't think we need the "backwards compatibility mode" at all. It doesn't fill any known need, and we can always add such a feature in the future if/when it's needed. I'll send out a PR to remove it.
Originally, the intention of this mode was for two use cases:
- New producer + old consumer. The thinking was that the producer can produce a "backwards compatible signature" and then some process afterward can convert to the old format. But why? Just have the producer generate the old format directly.
- Old producer (or existing signature) + new consumer. The thinking was that these existing signatures can be transformed automatically into "backwards compatible signatures" and then consumed by the new consumer. But why? Just have the consumer support both formats. It's going to need to do this anyway for real backwards compatibility (as Trishank explained).
Thus, the feature doesn't seem to serve any real purpose. Removing it will reduce complexity.
Hi Trishank. You bring up a very good point. After further thought, I don't think we need the "backwards compatibility mode" at all. It doesn't fill any known need, and we can always add such a feature in the future if/when it's needed. I'll send out a PR to remove it.
Originally, the intention of this mode was for two use cases:
- New producer + old consumer. The thinking was that the producer can produce a "backwards compatible signature" and then some process afterward can convert to the old format. But why? Just have the producer generate the old format directly.
- Old producer (or existing signature) + new consumer. The thinking was that these existing signatures can be transformed automatically into "backwards compatible signatures" and then consumed by the new consumer. But why? Just have the consumer support both formats. It's going to need to do this anyway for real backwards compatibility (as Trishank explained).
Thus, the feature doesn't seem to serve any real purpose. Removing it will reduce complexity.
I think I agree, but let me think about this a bit more with a demo.
@trishankatdatadog Bump, do you have any thoughts? If this makes sense, we can likely merge #19...