did we decide on this yet? i think it's fine, and probably the only real choice as i doubt they'll make another gcc release until like march/april probably.

Checking prior releases of GCC, one would need probably to wait until April or May for GCC 15.3. If we wait for this long, 2026b would definitely need to be built on top of GCC 16.2. The last x.2 releases came out around August. So that would align.

If we use GCC 15.2 as the basis for 2026a and GCC 15.3 for 2026b, I think that work on that should start very soon to avoid the versions of many packages being as close as we have in 2025a/b right now, so much so that there's not a huge benefit of having both.

If we'd start work on 2026a right now, here are the latest versions of some noteworthy packages we'd upgrade (compared to 2025b):

Compilers:

• GCC 14.3.0 -> 15.2.0
• LLVM 20.1.8 -> 21.1.8
• Intel 2025.2.0 -> 2025.3.1
• Python 3.13.5 -> 3.14.2

Build systems:

• CMake 4.0.3 -> 4.2.1
• Meson 1.8.1 -> 1.10.0
• Ninja 1.13.0 -> 1.13.2

Math libraries:

• OpenBLAS 0.3.30 -> 0.3.30
• BLIS 2.0 -> 2.0
• AOCL-BLAS 5.1 -> 5.2
• NVPL 25.5 -> 25.11
• FlexiBLAS 3.4.5 -> 3.5.0
• NumPy 2.3.2 -> NumPy 2.4.0
• SciPy 1.16.1 -> SciPy 1.16.3

MPI:

• OpenMPI 5.0.8 -> 5.0.9
• MPICH 4.3.2 -> 4.3.2
• impi 2021.16.1 -> 2021.17.x ( experimental support for MPI ABI & support for GCC 15 )

Some updates are noteworthy, others only have minor version bumps. OpenBLAS may or may not see a new release relatively soon (see OpenMathLib/OpenBLAS#5559).

One other noteworthy package update is libreadline (from 8.2 to 8.3), which is required for bash to work correctly if a distribution has updated. The latest bash (5.3) requires the latest libreadline (8.3) to work. This affects Fedora 44, Arch Linux, Ubuntu 26.04 and maybe more.

I would be surprised if we wouldn't be using GCC 15.2 as base for 2026a.

That said, we should have a discussion whether we actually want to keep doing two common toolchain versions per year.
So we may only have foss/2026 rather than having foss/2026a and foss/2026b.

I'm hoping to discuss this during the (virtual) EasyBuild Maintainers Summit (which is scheduled for 9 + 12 Feb'26).

I'm hoping we can kickstart the effort on the next common toolchain version earlier than that though, so I'm fine with merging this.

https://github.com/easybuilders/easybuild-easyconfigs/blob/develop/test/easyconfigs/easyconfigs.py#L984 should be updated as well at some point

That said, we should have a discussion whether we actually want to keep doing two common toolchain versions per year.
So we may only have foss/2026 rather than having foss/2026a and foss/2026b.

the suffix "a" doesn't have to imply that there would be "b", in fact we have skipped 2024b, but it would leave to door open if some wanted to bring up a 2025b. I don't think it's necessarily the compiler we want to desperately update, but rather the rest of the stack that might see interesting updates, and the toolchain refresh is our place to do such.
So maybe we end up a new toolchain every 10 months or something? There is no need to limit ourselves to the year as a basis in my opinion, the software out there certainly doesn't.