ci: drop Juju 3.3

[dimaqq]

Juju 3.3 has reached end of life.

🔸 Juju 3.3.7 - 10 September 2024
NOTE: This is the last release of 3.3. There will be no more releases.

https://documentation.ubuntu.com/juju/latest/reference/juju/juju-roadmap-and-releases/index.html?dfghjkl=#juju-3-3

Meanwhile, 8 integration tests are failing against Juju 3.3 specifically #1267

This PR removed Juju 3.3 from CI to close #1267

[dimaqq]

Discussion link: https://matrix.to/#/!wJiiHsLipVywuWOyNi:ubuntu.com/$q1dUM0LCcnffzykmp1uEXGlgGQ-QWOo_fQGfJCPwlIw?via=ubuntu.com&via=matrix.org

(no comments at this time)

[benhoyt]

Shouldn't we remove 3.1/stable while we're here?

[dimaqq]

Well if we went all in, we'd remove 3.0 3.1 3.1 3.3 3.4 from code and 3.1 3.3 3.4 from CI leaving only 3.5 3.6. wdyt?

Ref: #1270

[benhoyt]

Well if we went all in, we'd remove 3.0 3.1 3.1 3.3 3.4 from code and 3.1 3.3 3.4 from CI leaving only 3.5 3.6. wdyt?

Yeah, I reckon we should just do that.

[dimaqq]

Ahh, actually we can't just do that.
At least we can't remove all the stale 3.x schemas due to #1156 and #1157.
This library is stuck on the older CharmsFacade version for years (?).
Someone would need to find time to re-code charmhub charm resolution from series to bases.

The naive approach didn't work, I've tried in dimaqq#3

[james-garner-canonical]

I'm on board with just dropping 3.3 from CI as a start, since it's EOL and many integration tests are failing, which makes development more painful.

I think dropping the facades can wait till a separate PR given that python-libjuju currently supports some operations only through older facades.

Dropping other bases can wait too imo. 3.1 in particular seems to be more stable for some integration tests (e.g test_relate #1277), so it's probably useful to keep it in CI for now.