On 24 November 2015 at 04:32, Nate Finch <nate.fi...@canonical.com> wrote:
> Last week, I had trouble landing code in gopkg.in/juju/charm.v6-unstable,
> and using that code from master of github.com/juju/juju. I was hoping
> someone could help me figure out a way to avoid problems I've encountered.
>
> A couple times lately, commits that contain backward incompatible changes
> have landed in one of the repos juju depends on. No corresponding fixes
> landed in juju, so the HEAD of master of juju can't compile against the HEAD
> master of the dependent repo. Luckily, godeps insulates juju from these
> breaking changes, so the master of juju still builds using godeps.
>
> However, the problem comes when I try to land my own changes in the
> dependent repo (in this case in charm.v6), and update juju to use my
> changes. If I update dependencies.tsv to my commit in charm.v6, the repo
> now includes the breaking changes... and juju won't compile.
>
> Note that this is even true of code in a feature branch of juju, since the
> feature branch would still have the same incompatibility with the dependent
> repo.
>
> Anyone have ideas on how can we prevent incompatible changes landing in a
> dependent repo without the corresponding fixes landing in juju soon
> thereafter?
This was my fault, I'm afraid. I had hoped to land the juju changes very soon
after the incompatible charm.v6-unstable (note "unstable") changes landed,
but could not because master was blocked. I couldn't easily roll back the
charm changes as I'd already landed changes in several other repos that
used the new version, in necessary preparation for landing the change in juju.
Master remained blocked for most of a week (on the same bug AFAIR, even
though a fix had landed) - this is the real underlying problem here.
There is actually one possible solution here that I have used once in the past
when necessary, but I don't particularly recommend it. You can land
changes in a feature branch in the external repo (charm in this case)
and pin master to that. It works OK because git fetch fetches feature branches
as well as master, so godeps can correctly update to the feature branch
dependency.
I suspect doing this will end up being more hassle than it's worth - the
right solution is just to land your changes in the external repo as usual
and help master move forward to using it.
cheers,
rog.
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
