-
Notifications
You must be signed in to change notification settings - Fork 221
Open
Milestone
Description
| OS/Component | Linux - Ubuntu LTS (24.04/Noble) | Linux - Debian | Linux - Arch | Linux - Gentoo | BSD | OS X | Windows -MinGW | Windows - ? |
|---|---|---|---|---|---|---|---|---|
| C++ - g++ | 13.2.0 | 14.3.0 | ||||||
| C++ - clang | 18 | 20.1.7 | ||||||
| Protobuf | 3.21.12 | 30.2 | ||||||
| Libmicrohttpd | 1.0.0 | 1.0.1 | ||||||
| Python | 3.12 | 3.13.3 | ||||||
| Java | openjdk21 | openjdk21 |
Assumptions:
- Python 3 only - min version 3.??
- Protobuf 3 only
- Min C++??
- Min Java ??
Proposal, from the above:
- Fork master to develop
- Drop any CI versions that are too old
- Add new CI versions to match minimum and above - Expect these new ones to fail
- Alter configure to require these new minimums - New ones will continue to fail due to outstanding bugs
- Redirect existing PRs that fix these issues at develop, ideally merged into some sort of super PR that just fixes things in one big bang, but see how we go there
- Get people to thoroughly test the now-working develop branch
- Pre-release pull in any remaining work that got merged into master having fixed up as required.
- When happy release as 0.12.0 (possibly release master as 0.11.0 as a legacy release at the same time)
I think this gives a manageable way to get off our current target whilst still allowing some parallel work around doing that, whilst also resolving the large number of (mostly mine) unmerged PRs (and worse uncommitted code) for stuff like E1.33, which I think just plowing ahead on the master branch would provide a nightmare of merge conflicts and possibly a broken branch.