New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stabilize manifest and lock #276

Closed
sdboyer opened this Issue Mar 2, 2017 · 0 comments

Comments

Projects
None yet
1 participant
@sdboyer
Copy link
Member

sdboyer commented Mar 2, 2017

A crucial early goalpost for dep is to have stable, committable manifest and lock files. It's a "1.0"-ish moment: once we have an implementation that we're satisfied with, we will make a backwards-compatibility guarantee that will be good throughout dep's lifetime: from that point on, any version of dep will be able to read and operate from any manifest+lock generated from that point, or later.

Note that this does NOT guarantee all versions of dep will operate the same way. We do plan to add more fields to cover more behaviors; earlier versions of dep will not, of course, recognize these fields. It is also possible that newer versions of dep may behave somewhat differently when given the same files as earlier versions, but we will endeavor to keep this to a minimum, and have it be strictly additive where it does occur.

We will also endeavor to minimize transitional pain between dep and how the go toolchain ultimately operates after dep is absorbed - though we can't promise that transition will be entirely automated.

This is the epic/meta-issue for this goal; there's also a milestone. All the issues on that milestone involve some kind of breaking modification to the files. Once they're done, we can call the files stable.

There are also a number of issues without backwards-compatibility implications. They're not part of this issue, and can be found under the metadata-additions label.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment