That's an interesting observation and I think I agree.
The general rule is probably something like this:
- If a type is part of the exported API of a versioned package and the
package is changed to import that type from somewhere
else, the package's version must be incremented.
Given that versions usually apply to repositories, not packages,
that does unfortunately mean that all the repositories which
export testing functionality using gocheck need to have
their versions incremented.
I don't think it all has to happen at the same time, because APIs
remain stable. It does mean that juju-core can only be updated
after all of its dependencies have been updated though.
cheers,
rog.
On 22 September 2014 12:14, John Meinel <j...@arbash-meinel.com> wrote:
> So Bogdan Teleaga was kind enough to put in the effort to move all of our
> source trees to start importing from "gopkg.in/check.v1" rather than
> depending on "labix.org/gocheck".
>
> However, this means that if we land those changes, code that depends on the
> testing infrastructure provided by those packages will break because a
> labix.org/gocheck.Suite is not a gopkg.in/check.v1.Suite.
> And even further, Checkers are different (so we have to update
> github.com/juju/testing/checkers/ before other code.)
>
> Since we're doing "versioned stable APIs" I'm wondering if this means things
> need a version bump. I *think* the answer is yes, because if you just did:
> go get gopkg.in/juju/charm.v3
>
> Before the change, you could run "cd github.com/juju/juju; go test ./..."
> but if we change just charm.v3 but not juju/juju then "go test ./..." just
> breaks.
> Thus, changing your testing infrastructure while it doesn't change your API
> it changes your *test interface* which makes it an unstable API break.
>
> And we have the unfortunate process that *all* of our code is tested via
> 'gocheck' which means that we have to update-the-world to rev its import.
>
> Certainly I'd rather not do the work if we don't have to, so I'd like other
> people's input if we feel we have to.
>
> John
> =:->
>
>
> --
> 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
