Stabilize manifest and lock #276
Description
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.