build: Drop build support on vanilla Ubuntu Jammy 22.04 LTS? #34979

1. 
   maflcko commented at 8:57 am on April 1, 2026: member

   Just wondering when it would be acceptable to drop build support on vanilla Ubuntu Jammy 22.04.

   According to https://documentation.ubuntu.com/project/release-team/list-of-releases/ EOSS will be in June 2027.

   Thus, I think it would be fine to drop support with the release of Bitcoin Core 33.0 in April 2027. Affected users can then decide if they want to upgrade their OS, or temporarily stay on Bitcoin Core 32.x for as long as it is supported (~1y).

   I presume anyone with an Ubuntu subscription wishing to stay on the older LTS is an expert user who can figure out how to install a more recent version of cmake and their compiler and then compile using depends. C.f. https://github.com/bitcoin/bitcoin/blob/master/doc/dependencies.md#dependencies

   The benefits would be to be able to drop workarounds in code and CI tooling around supporting older build toolchains. Specifically, it would

   • come with the last bit of C++20 support which may be useful (std::format).
   • allow more modern cmake features (not sure if there are any of interest, cc @hebasto)
   • …

   Note this is about build support, and the runtime support of the pre-built release binaries is tracked in https://github.com/bitcoin/bitcoin/blob/8e789322c5aef90c7eb3b71c2876e85f7208cf8c/contrib/guix/symbol-check.py#L17-L36

2. maflcko added the label Brainstorming on Apr 1, 2026
3. maflcko added the label Build system on Apr 1, 2026
4. maflcko added this to the milestone 33.0 on Apr 1, 2026
5. 
   hebasto commented at 10:39 am on April 1, 2026: member

   ACK. The same topic was discussed during this IRC meeting.

   I agree with all the points mentioned in the OP.

   Just wondering when it would be acceptable to drop build support on vanilla Ubuntu Jammy 22.04.

   Using the same arguments, my answer is: in the current (v32) release cycle. I believe that it is acceptable for both tech-savvy individuals who choose to stay on Ubuntu 22.04 LTS and for businesses.

   I presume anyone with an Ubuntu subscription wishing to stay on the older LTS is an expert user who can figure out how to install a more recent version of cmake…

   Installing CMake from https://cmake.org/download/ is a no-brainer. So I’m still hoping to bump the minimum required CMake version from 3.22 to 3.25 in the current release cycle, regardless of the decision about supporting Ubuntu 22.04 as a build platform.

6. 
   purpleKarrot commented at 1:31 pm on April 1, 2026: contributor

   Double ACK. I also agree with all the points and I would even go a step further.

   The current approach of requiring that all build dependencies must be more than five years old simply does not scale and we even rely on the fact that our dependencies don’t follow the same philosophy. Instead, we should strive for more “live at head”.

   I presume anyone with an Ubuntu subscription wishing to stay on the older LTS is an expert user who can figure out how to install a more recent version …

   On the contrary. My assumption is that anyone wishing to stay on an old LTS also wants to stay on an equally old release of our software, while anyone who is happy to build our software from source does not mind building the dependencies. But even in the case where someone actually wants to build our code on an old LTS:

   Installing CMake from https://cmake.org/download/ is a no-brainer.

   And so is installing CMake, GCC, Python via conda/mamba.

   Essentially, we need to understand that we have different stake holders with slightly conflicting interests.

   • Some users may require building our top releases on legacy platforms.
   • Some users may want to consume the kernel library via the Common Package Spec (CPS).
   • Developers may be happier with later versions of C++, CMake, Python, …

   So we need to make a decision which of those stake holders should be treated as first class citizens, and which are treated as second class citizens. At the moment it seems the interests of the “legacy users” are put above all others and I am afraid that is not the best approach. I am not saying their interests should be dismissed. I am just saying that they should come second.

   So my recommendation would be: Use guix and anaconda as the baseline. At the time of writing, guix provides CMake version 4.1.3 (link), while anaconda provides version 4.2.3 (link). Hence, I would set the minimum version of CMake to version 4.1.

   Back to the original question: what about Ubuntu 22.04? I think the platform should remain to be supported, but not in the vanilla flavor. Instead, modern build dependencies should be installed with micromamba.

7. 
   fanquake commented at 1:41 pm on April 1, 2026: member

   My assumption is that anyone wishing to stay on an old LTS also wants to stay on an equally old release of our software

   Why? I don’t think this is true, because we see issues opened from users using/pinned to old OS’s, that have compatibility issues when we bump libc requirements for new releases.

8. 
   purpleKarrot commented at 1:54 pm on April 1, 2026: contributor

   compatibility issues when we bump libc requirements for new releases.

   Do they have issues building new releases or running released binaries? This issue is about build support and I gave an answer to that in my post above: They can install build dependencies like cmake, gcc, python via a non-system package manager like mamba. The libc incompatibility is not an unsolvable problem either. The question remains: Who should be treated as the second class citizen.

9. 
   maflcko commented at 5:13 pm on April 1, 2026: member

   My assumption is that anyone wishing to stay on an old LTS also wants to stay on an equally old release of our software

   This is not the intention. According to https://bitcoincore.org/en/lifecycle/ it is simply not supported to run that old releases at all.

   anyone who is happy to build our software from source does not mind building the dependencies.

   Not sure this is true. Installing each dependency individually from the upstream vendor may appear trivial one-by-one, but going out and installing all (including the runtime deps from https://github.com/bitcoin/bitcoin/blob/master/doc/dependencies.md#dependencies or all the build toolchain ones from https://github.com/bitcoin/bitcoin/blob/master/depends/README.md#usage) can easily be overwhelming.

   Also, asking builders to use a third-party package manager to do it for them doesn’t seem ideal, because every additional dependency (including the package manager) can increase the surface of vulnerability.

   Finally, when looking at other C++ projects, they seem to be even more conservative. E.g. LLVM isn’t even on C++20, when it would be presumably easy to require a recent clang in a two stage build (https://discourse.llvm.org/t/rfc-raise-the-minimum-compiler-requirements-to-move-toward-c-20/88894/27)

10. 
    hebasto commented at 5:42 pm on April 1, 2026: member

    Also, asking builders to use a third-party package manager to do it for them doesn’t seem ideal, because every additional dependency (including the package manager) can increase the surface of vulnerability.

    Yes, let’s not introduce support for more package managers. We already have code specific to Homebrew and vcpkg.

11. 
    purpleKarrot commented at 9:19 pm on April 1, 2026: contributor

    it is simply not supported to run that old releases

    Which simply means that there is no plan for further point releases. It is not something that will stop people from using old versions, as usage statistics show. The license states that the software is released without warranty of any kind.

    asking builders to use a third-party package manager to do it for them doesn’t seem ideal

    …

    We already have code specific to Homebrew and vcpkg.

    …

    Yeah. We cannot support one single environment manager for all legacy platforms, because we already support two specific package managers for macOS and Windows respectively. So this is why we can’t have nice things, I guess.

    But I repeat myself: It all boils down to the question: Who do we want to treat as second class citizens.

12. 
    maflcko commented at 6:59 am on April 2, 2026: member

    It is not something that will stop people from using old versions, as usage statistics show.

    Right, of course everyone is free to do whatever they want. However, there are no auto-updates, so I think updates should be easy, both for self-compilation, as well as for the release binaries, so that most users have an option to update if they wish.

    I know running the release binaries is unrelated to self-compilation, but the glibc bump may have been too early, so it may be good to not repeat the same mistake for self-compilation. Ref:

    4322025-09-18T16:26:54 <darosior> achow101: the nodl boxes are stuck because of our glibc bump in 28

    Still unrelated, but I wonder if and how that resolved by now.

    Who do we want to treat as second class citizens.

    I think we should make it straightforward for users to compile and update the software on commonly used and supported operating systems. What that means specifically, depends on the operating system, but for Ubuntu, I’d say it is what they call “Standard Support”.

    To give some more stats: I know the snap ships the release binaries, but I think the Ubuntu distribution is likely similar to those self-compiling. (Obviously, every non-Ubuntu distro isn’t representative, as snap is usually only found on Ubuntu). The stats currently show 22.04 at second place, after 24.04:

    https://snapcraft.io/bitcoin-core

13. 
    hebasto commented at 2:28 pm on April 2, 2026: member

    So we need to make a decision which of those stake holders should be treated as first class citizens, and which are treated as second class citizens.

    Here is my vision for a multi-tier support model for build platforms.

    Tier 1

    Platforms that meet the following criteria:

    1. Documented build notes in this repository.
    2. CI jobs in this repository.
    3. The latest two releases, unless documented otherwise. For Ubuntu, this means the two most recent LTS releases. For Windows 11, it means the two most recent versions.

    Our promise / User expectations

    1. All build tools are available either by default or via a standard, platform-specific installation routine with no extra configuration steps.
    2. All dependencies for dynamically linked binaries are available via the default package manager.
    3. Building statically linked native binaries with depends works out of the box (not applicable to Windows).

    Tier 2

    Same as Tier 1, except that CI jobs are hosted elsewhere.

    Our promise / User expectations

    Same as Tier 1, but on a best-effort basis.

    Tier 3

    Same as Tier 2, but there are no documented build notes in this repository.

    Our promise / User expectations

    No promises.

14. Jonathancombs782 referenced this in commit 1ff392fe2d on Apr 5, 2026
15. 
    maflcko commented at 3:44 pm on April 7, 2026: member

    So I’m still hoping to bump the minimum required CMake version from 3.22 to 3.25 in the current release cycle, regardless of the decision about supporting Ubuntu 22.04 as a build platform.

    Not sure if this has any benefits. From the IRC, there is mentioned:

    <hebasto> This gives us a few useful features such as (1) file sets; (2) COMPILE_WARNING_AS_ERROR; (3) better support for IPO/LTO; (4) scope management

    However, (2) COMPILE_WARNING_AS_ERROR already is used today, without a bump. As for LTO: I wonder who is even using it, given that it increases the risk of miscompilation or ICE. And “scope management” as well as “file sets” are likely purely internal cleanups, similar to std::format. While they may be nice, I think there is no rush to have them 6mo earlier.

Contributors
maflcko hebasto purpleKarrot fanquake

Labels
Brainstorming Build system

Milestone
33.0