Versioning of libjuju

[Tim Van Steenburgh]

Yeah, thanks for bringing this up. I think that your strawman is the
correct approach. To make this happen we really just need to keep the old
facade versions around instead of blowing them away every time we
regenerate the facades for a new version of juju.

On Wed, Jan 18, 2017 at 2:38 PM, Adam Collard <adam.collard at canonical.com>
wrote:

> Hi all,
>
> Something that came up at today's Juju Show[0] was how versioning of
> libjuju should work. Should we have 1:1 releases of libjuju with associated
> Juju's (I'm -1 - it could get very messy very quickly) or can we have one
> libjuju version talking with multiple Juju versions?
>
> As far as I understand it, the way that libjuju uses generated code from
> the Golang source makes it non-trivial to generate dynamically from a
> remote connection.
>
> Strawman: what if we split the current generated blob[1] into each facade,
> and further into each facade version. libjuju is constantly updated with
> the stubs of latest facade version from Juju releases as they come out.
> When libjuju connects, it does a negotiation to work out what's the latest
> facade version that both it and the remote API know about.
>
> Thoughts?
>
> Adam
>
> [0] https://www.youtube.com/watch?v=Lsbo7f7yMxY
> [1] https://github.com/juju/python-libjuju/blob/master/
> juju/client/_client.py
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170118/c75d4bd7/attachment.html>