There are packaging nuances to versioning On Tue, Sep 23, 2014 at 9:57 AM, Nate Finch <[email protected]> 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 -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
