Versioned Imports and dependencies.tsv

[Domas Monkus]

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.peppe at canonical.com>
wrote:

> On 23 September 2014 13:23, Dimiter Naydenov
> <dimiter.naydenov at 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 at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140923/ad222ba5/attachment.html>