Re: Versioned Imports and dependencies.tsv
AFAIK I created v4 because of a breaking change to testing importing gocheck from its new location, but we have to update the world before we can land the dependencies.tsv changes. John =:- On Sep 23, 2014 4:24 PM, Dimiter Naydenov dimiter.nayde...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I noticed a recent change in juju/juju bumping the revision of a sub-repo (in this case juju/charms), which should be fine if the sub-repo wasn't imported with a versioned path (github.com/juju/charm.v3). The commit in question is: https://github.com/juju/juju/commit/7694614984932598535639e09129820f15b9d58d The problem is with gopkg.in/juju/charm.v3 specifically, as there are a few other cases of bumping the sub-repo revision in dependencies.tsv and not issuing a new version: https://github.com/juju/juju/commit/7694614984932598535639e09129820f15b9d58d https://github.com/juju/juju/commit/c35c4dfb19544667225a3e4b5141c85ccbc011bd In fact there is a v4 branch: https://github.com/juju/charm/compare/v4 which is already 3 commits ahead of v3, but juju-core still uses v3. My point is, we need to discuss and define a policy how to handle dependencies with versioned import paths. From a user's perspective, importing gopkg.in/juju/charm.v3 should (AIUI) *always* pull the same source and you can rely on it being stable and not need to update it until you need something from v3. For all other cases (non-versioned paths) we use godeps with handles it nicely, without claiming to provide stable versions. So, let's agree to only use versioned imports as dependencies as they were intended: 1) Stick with (e.g.) gopkg.in/juju/charm.v3 in both dependencies.tsv and across the juju-core source. 2) If the sub-repo has changes that juju-core needs, create a vX branch in the sub-repo with the changes (X = current+1, i.e. branch v4 from v3) and land this first, then change dependencies.tsv in juju-core to use the new gopkg.in/juju/charm.v4 and its revision. Any thoughts? - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUIWZcAAoJENzxV2TbLzHwfy0H/1/Mzl+sgmS+GQqdjSqn2HeQ JH3I2Eex3iGOiJnftIjM79Sai4JjGl4F21zkKIkEowx6RcAWAKXjYGqg5+cH33Gc w6JSYuC19n4kXG+BMZn4l/Cj6idKG5o5W2pPhTTM1RqPCSAP1H5ChkSJKWHEDXvz Tkts85VBvx2iasd1sDF7UgulehFkwsHc6xZ19sjvS2CVeI8qczIwAN+oAxwzCeKN NIEeaGNrLmemwelIxRAbr9d6/4kwySGI95G6X3bBVFs/WWgSBJvkzS7op3+i+DgN uQDT9w6DKZekESmEcJOKuExVY5n+WarJfObUdIxXa9IlZlEFOCqcWu/OjxIapFs= =7Yys -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Versioned Imports and dependencies.tsv
On 23 September 2014 13:23, Dimiter Naydenov dimiter.nayde...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I noticed a recent change in juju/juju bumping the revision of a sub-repo (in this case juju/charms), which should be fine if the sub-repo wasn't imported with a versioned path (github.com/juju/charm.v3). The commit in question is: https://github.com/juju/juju/commit/7694614984932598535639e09129820f15b9d58d The problem is with gopkg.in/juju/charm.v3 specifically, as there are a few other cases of bumping the sub-repo revision in dependencies.tsv and not issuing a new version: https://github.com/juju/juju/commit/7694614984932598535639e09129820f15b9d58d https://github.com/juju/juju/commit/c35c4dfb19544667225a3e4b5141c85ccbc011bd In fact there is a v4 branch: https://github.com/juju/charm/compare/v4 which is already 3 commits ahead of v3, but juju-core still uses v3. My point is, we need to discuss and define a policy how to handle dependencies with versioned import paths. From a user's perspective, importing gopkg.in/juju/charm.v3 should (AIUI) *always* pull the same source and you can rely on it being stable and not need to update it until you need something from v3. For all other cases (non-versioned paths) we use godeps with handles it nicely, without claiming to provide stable versions. 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. cheers, rog. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Versioned Imports and dependencies.tsv
Disclaimer: one of the commits mentioned here is mine. I think I agree with Roger on this - as long as the changes to a package are backwards compatible, incrementing the version number seems a bit over the top. To begin with, it would mean quickly incrementing versioned package versions (would charm.v157 even be considered a version?), lots of unnecessary changes in the juju codebase each time a dependency is updated (again, in a backward-compatible way) and in this case godeps and version packages would start solving the same problem in two not directly compatible ways. Domas On Tue, Sep 23, 2014 at 4:52 PM, roger peppe roger.pe...@canonical.com wrote: On 23 September 2014 13:23, Dimiter Naydenov dimiter.nayde...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I noticed a recent change in juju/juju bumping the revision of a sub-repo (in this case juju/charms), which should be fine if the sub-repo wasn't imported with a versioned path (github.com/juju/charm.v3). The commit in question is: https://github.com/juju/juju/commit/7694614984932598535639e09129820f15b9d58d The problem is with gopkg.in/juju/charm.v3 specifically, as there are a few other cases of bumping the sub-repo revision in dependencies.tsv and not issuing a new version: https://github.com/juju/juju/commit/7694614984932598535639e09129820f15b9d58d https://github.com/juju/juju/commit/c35c4dfb19544667225a3e4b5141c85ccbc011bd In fact there is a v4 branch: https://github.com/juju/charm/compare/v4 which is already 3 commits ahead of v3, but juju-core still uses v3. My point is, we need to discuss and define a policy how to handle dependencies with versioned import paths. From a user's perspective, importing gopkg.in/juju/charm.v3 should (AIUI) *always* pull the same source and you can rely on it being stable and not need to update it until you need something from v3. For all other cases (non-versioned paths) we use godeps with handles it nicely, without claiming to provide stable versions. 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. cheers, rog. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Versioned Imports and dependencies.tsv
There are packaging nuances to versioning On Tue, Sep 23, 2014 at 9:57 AM, Nate Finch nate.fi...@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 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
