[Canonical-tech] Handling active dependencies in Go

[roger peppe]

I should probably provide an example:

I assume that all versioned package paths contain a version number path
element, for instance, "v3" (this corresponds with existing practice, and
there's only a single false positive when looking through all the packages
on godoc.org - "github.com/v64/gomaybe/lib/gomaybe/util"; we could live
with that or exclude repo user names as a special case).

Say we're using launchpad.net/goose/v1, and we want to change goose
in a backwardly incompatible way.

We'd branch a new series of goose, say v1, and in the goose root
directory, we'd run:

    govers launchpad.net/goose/v2
    bzr commit -m 'govers launchpad.net/goose/v2'

which would update all the import paths to use the new version.

Then when we're ready to make juju use v2, we'd run the same commands
in the root of the juju-core tree, then fix any source incompatibilities as
appropriate before proposing the changes.


On 21 December 2012 11:28, roger peppe <roger.peppe at canonical.com> wrote:
> As a hopefully positive contribution to this discussion, I've just
> knocked up a little tool that should make it easier to
> move forward with option B above.
>
> I've called it govers, and it's at launchpad.net/govers.
> You can install it with go get.
>
> Hopefully this should make it easy to switch between versions
> and make sure that consistent versions are used throughout
> a program.
>
> Thoughts?