dvc: Don't fail because of extra keys in dvc file

Thanks for the thoughtful response @skshetry.

This is only about read-only operations for historical commits. I do not expect those extra keys to be useful or be preserved if we do a write operation.

We are not a typical software project in this way. Like git, which is also hesitant to break backwards compatibility, part of our value proposition is to maintain the immutable history of your project. If our major version updates make the prior history of your project completely unusable, I think it’s more severe than a typical breaking change where you have a choice to update your scripts and have everything work again. Even if it is rare, it is most painful for our most loyal users who have projects that stretch back to 0.x or 1.x. They cannot upgrade without rewriting their project history, which defeats much of the purpose of using DVC.

For most of the examples you give, it seems like we could allow users to read the status of their project, garbage collect it, or get/checkout/pull data from that revision. If we still warn users during these scenarios, I think the benefit of not making your project history unreadable outweighs the risks of unexpected behavior. The latter is I think a reasonable expectation of breaking changes. The former feels severe enough that I don’t think we can recommend upgrading unless you are starting with a fresh project. Is it better for users if we leave it as is?

• vars: Most likely, on this case we cannot parametrize and it’ll fail anyway. So this cannot be handled.

Good point. I guess ignoring the errors here is not that useful. This raises the question for me of whether we should so severely deprecate it right now when our only justification was that it’s complicated. Again, is it better for users in the current state? Even if I update the project, there will always be a mismatch where old commits only work with ❤️.0 and newer commits only work with >=3.0. How can I ever garbage collect or fetch the history of my project?

historically, we have been okay with breaking backward compatibility We made a breaking change, and I’d like to stick to it unless the impact is really severe as you have said.

Personally, I was not fully conscious (nor recall discussing) that we would break the parsing history of 2.X files (in some cases), due to Schema validation. I also don’t recall discussing that 2.X DVC would not be able to parse 3.X dvc.yaml/lock (because of the extra hash: md5 key)

I recall discussing breaking 1.X parsing, dropping CLI features, cache migration, etc but not this.

If all the rest were aware of this, ok, but I would have preferred to discuss the migration/release process in more detail.

@skshetry We should add checkpoints back to the schema

I also don’t recall discussing that 2.X DVC would not be able to parse 3.X dvc.yaml/lock (because of the extra hash: md5 key).

This is forward compatibility, which is never promised, not even in minor versions of dvc. And we have broken this so many times before.

@dberenbaum, I agree with what you have said, and I said the same thing when I kept compatibility for .dvc files when we introduced dvc.yaml files. Historically, we have been okay with breaking backward compatibility, even for history and the suggestion has always been to rewrite history, however painful that is (not saying that I agree with that suggestion).

How can I ever garbage collect or fetch the history of my project?

You can still use 2.x version of dvc. But I think we are exaggerating the issue here. DVC 3.x is largely compatible. Also, looking at the (non-existing) tickets other than this and reactions in this issue, I am not convinced the problem is as severe as you have said. We made a breaking change, and I’d like to stick to it unless the impact is really severe as you have said.

@skshetry we can explicitly handle and do any monkey patching to unblock this. (longer term I think we need a specific mode in DVC). DVC itself is also broken for its history I think (e.g. commands like metrics diff, VS Code extension, etc).

@skshetry WDYT, can we relax those?

Not possible without explicitly ignoring/handling those.