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 <[email protected]> wrote: > On 23 September 2014 13:23, Dimiter Naydenov > <[email protected]> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
