Versioning of libjuju

[Adam Collard]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170118/f32b5fd7/attachment.html>