Skip to content
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.

Stabilize manifest and lock #276

Closed
sdboyer opened this issue Mar 2, 2017 · 0 comments · Fixed by #644
Closed

Stabilize manifest and lock #276

sdboyer opened this issue Mar 2, 2017 · 0 comments · Fixed by #644

Comments

@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 subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant