[Proposal] General rule for minimum package versions and distribution support

[tobtoht]

It would be nice if we could reach consensus on a general rule for minimum package versions and distribution support. This comes up occasionally (e.g. #9443, #9171, #8922) and it always seems to spark a debate that goes nowhere.

I would like to propose that we guarantee support for distributions until EOL date + 1 year, to give users ample time to upgrade their machine.

Users on distributions that don't package the minimum version of a required library can still build Monero using make depends.

Why?

• To give developers access to new library features when they believe this would benefit their code.
• To reduce maintenance burden associated with guaranteeing compatibility with a wide range of library versions / compilers / operating systems.
• To prevent us from having to argue about this every time a minimum version change is proposed.

Example

OS	EOL date	Boost version	Supported
Ubuntu 16.04	02 Apr 2021	1.58	No
Ubuntu 18.04	21 May 2023	1.65	No
Ubuntu 20.04	02 Apr 2025	1.71	Yes
Debian 9 (LTS)	01 Jul 2022	1.62	No
Debian 10 (LTS)	30 Jun 2024	1.67	Yes
Debian 11 (LTS)	31 Aug 2026	1.74	Yes

With the proposed rule, we would currently guarantee support for Boost 1.67 at minimum.

A more complete list

Build tool	Version
binutils	2.31
cmake	3.13.3
curl	7.64.0
cxx standard	c++17
doxygen	1.8.13
gcc	8.3.0
graphviz	2.40.1
gtest	1.8.1
make	4.2.1
python	3.7.3
Library
boost	1.67
hidapi	0.8.0
libsodium	1.0.17
libusb	1.0.22
libzmq	4.3.1
openssl	1.1.1n
protobuf	3.6.1.3
readline	7.0
unbound	1.9.0
Runtime
glibc	2.28

Operating system	Version	Until
Windows	10 (21H2)	11 Jun 2025
macOS	11	26 Sep 2024
Debian	10	30 Jun 2025
Ubuntu	20.04	02 Apr 2026
FreeBSD	12	31 Dec 2024
Android	11	05 Feb 2025

[iamamyth]

I support this rule; it's exactly what motivated my comment about upgrading to Boost 1.67 on #9443.

[0xFFFC0000]

I support this proposal. I think we need a well defined / official approach like this.

We can discuss more about the details and versions. But the proposal itself is very needed.

[tobtoht]

I don't think EOL + 1 year is aggressive. Users (and devs) shouldn't be running security sensitive software on distributions that no longer receive security updates. It doesn't make sense to waste development time or withhold features to encourage bad practices.

Official binaries would continue to work on 18.04 (because we statically link Boost). Development builds would continue to work on Ubuntu 18.04 using depends. I'm not aware of any sites that have statistics, and I'm not sure how accurate they would be.

Keep in mind that if the version bump goes into master, it will only start affecting release branch builds when we branch from master, which doesn't happen that often (typically only when we hardfork?).

[selsta]

@tobtoht I deleted my comment because I misunderstood your proposal

[tobtoht]

Ah, the page hadn't updated. Yes, to clarify: this isn't about dropping support for anything the minute we reach the EOL + 1 year mark. We would guarantee support for that long and update a minimum when there is a reason to.

For example:

• feature x isn't possible without a newer library version
• feature x is better implemented with a newer library version
• there is a security benefit to updating the minimum (if it affects release builds)
• the minimum version is causing breakage for another change
• there is ongoing maintenance work associated with keeping support for the minimum version
• updating the minimum version doesn't affect anyone (and there is some benefit to bumping)