On 24 November 2015 at 15:51, Eric Snow <eric.s...@canonical.com> wrote: > On Mon, Nov 23, 2015 at 9:32 PM, Nate Finch <nate.fi...@canonical.com> wrote: >> Last week, I had trouble landing code in gopkg.in/juju/charm.v6-unstable, > > I had a similar experience last week with backward-incompatible > changes in the utils repo. :( > >> 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. >> >> [snip] >> >> Anyone have ideas on how can we prevent incompatible changes landing in a >> dependent repo without the corresponding fixes landing in juju soon >> thereafter? > > I'd recommend avoiding backward-incompatible changes if at all > possible. Often the temptation is to "fix" some signature while > you're working on related code. Sometimes you really need a different > signature. Either way, almost every time you can instead introduce a > new function with the new signature and deprecate the old one. Using > that approach you do not break backward compatibility and thus do not > cause the problem for dependent repos that you've described.
+1 to that. Unfortunately the charm change was a much bigger one (closely related to the very reason that charm.v6-unstable was created) so that wasn't an option there. Sometimes you've just gotta bite the bullet. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
