Hey folks 
A lot of active development has been in place in pylibjuju and we had good traction for both 2.9 and the master branch. We released very recently the 2.9.44.1 and 3.2.2.0, and more are coming soon. Thanks to everyone who contributed by taking the time to open PRs, issues, and participated in discussions, etc., we love you all 
One of the common questions/discussions we had along this process was how to maintain the compatibility with Juju controllers, i.e. which version of pylibjuju is compatible with which version of Juju?
This comes up especially important in charmers doing integration tests, as they need to have an IF in their codebase if they need to test against both 2.9 and 3.x controllers. Hopefully that will change soon, but I’ll come back to that later.
Based on @beliaev-maksim’s and @dnplas’s suggestion, I wanted to clarify for pylibjuju users, that currently we have two tracks of releases on pylibjuju: the 2.9 track that supports a 2.9.x Juju controller; and the 3.x track that supports a 3.x Juju controller. That means, that if you’re running against a Juju controller that’s <= 2.9, then you need to pin pylibjuju to whatever the latest release of the 2.9 track is (currently it’s 2.9.44.1). But here’s the kicker, if you’re using a Juju controller that’s 3.x, then you don’t need to pin pylibjuju at all. All you need is
pip install juju
We test pylibjuju against whatever the latest Juju release is out there at the time. However, through the Juju API, we don’t do version sniffing in pylibjuju, we negotiate facade versions. Therefore, if the latest Juju is 3.2 for example, pylibjuju is still testing most of the facades that are used in < 3.2. The only facade versions that are no longer being tested are the ones that are different between 3.1 and 3.2 (i.e. the ones that were revved in the 3.2 API). This is a long winded way of saying, if you’re working with a 3.x controller, then don’t worry about the version, pylibjuju will take care of you 
(introducing a test matrix might also prove to be useful in communicating confidence and maybe early detection of compatibility issues)
A note that might be important here is that if you find yourself in need to pin pylibjuju in any release in the 3.x track, that means somewhere down the line we’re breaking compatibility either in pylibjuju or in the Juju API, and that is a bug and needs to be fixed.
Going back to my early mention of running against both 2.9 and 3.x at the same time, based on our discussions and feedback we got in the Charm Engineering Sync earlier, I’m working on a branch on the side that will support both 2.9 and up to <= 3.1 to give people a solid ground to migrate their code from 2.9 to 3.x without worrying about pylibjuju compatibility (i.e. basically pylibjuju hauls that IF in your code for you and takes care of the underlying -major- version negotiations behind the scenes)[*]. So basically, whoever wants to use an older version will pin to that until they’re ready to move. And later on, for running against any Juju controller that is > 3.1, they can release the pin and just do pip install juju and be happy with their lives. 
We’ll also follow the same recipe moving forward, to support the last minor of the previous major when moving onto a new major. For example, when 4.x comes around, we’ll split into a branch that will support, say 3.9 and 4.0 at the same time, providing solid ground for migration, while the edge will follow the latest 4.x. The same will apply, whoever keeps up with the recent versions will be just fine, the pip install juju will continue to take care of everything. Whoever wants to stay in an older version will have to pin. I’m personally hoping that by the time 4.x is out the 2.9 will be a good old historical track we keep just for nostalgia 
Hope this clears things a bit for pylibjuju enthusiasts. Please don’t hesitate to share your thoughts in the comments down below or on the MM, and let your contributions keep coming with new feature requests, bug reports and PRs.
Cheers, everyone!
[*] We actually have a branch that did that for a while (support both 2.9 and 3.x at the same time), and that was the 3.0.4 release. After that we split into the 2.9 and 3.x tracks. We did not anticipate people would stay in 2.9 this long. No worries, the new branch will take care of that soon