Versioned Imports and dependencies.tsv

[Curtis Hovey-Canonical]

There are packaging nuances to versioning

On Tue, Sep 23, 2014 at 9:57 AM, Nate Finch <nate.finch at canonical.com> wrote:
...
>> That's not quite how it works. For versioned import paths, the version
>> is about the API, not the exact implementation. It's entirely
>> OK to add new (backwardly compatible) features to a package that
>> has a versioned import path (see "When to change the version" in
>> http://gopkg.in for details on this).
>>
>> We use godeps to guarantee stable builds. That means that
>> even in the presence of versioned import paths, we still want
>> to pin the dependencies for testing purposes, so that we
>> get reproducible tests and builds.
>>
>> Thus godeps and use of gopkg.in are orthogonal, and I think
>> that the commits you mention look fine to me.

Ubuntu knows that golang will pull in sub-deps and that it doesn't
enforce versioning. They have asked that we document every sub-dep
that juju requires and identify changes between versions.

Ubuntu accepts godeps and dependencies.tsv as the definition of what
the tarball contains. The rules to make a tarball used to test merges
and ci now require the top-level packages to be included in
dependencies.tsv. An error is raised when the tarball has directories
that do not match dependencies.tsv. Ubuntu will (and does) review the
changes to micro versions. We defend each change we make. If a
top-level package changes without a documented reason, the juju
release will be rejected.

Our privilege of placing newer versions of juju into LTSs is also our
responsibility to know why each change that is merged is needed and we
have documents and tests that show it is safe.



-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui