CDT 12.1.0 seems to require the latest version of Eclipse (2025-06)

[andrew-tram]

I'm on Eclipse 4.31 and have updated CDT to 12.0 without issues. But when trying to update to 12.1.0, it look like it requires Eclipse to be 2025-06 (4.36).

Is this intentional? I wouldve figured this type of hard requirement would trigger a major version increment of CDT and not just a minor increment.

Cannot complete the install because one or more required items could not be found.
  Software being installed: C/C++ Development Platform 12.1.0.202506041907 (org.eclipse.cdt.platform.feature.group 12.1.0.202506041907)
  Missing requirement: Eclipse C/C++ Development Tools 12.1.0.202505191828 (org.eclipse.cdt 12.1.0.202505191828) requires 'osgi.bundle; org.eclipse.ui.intro [3.7.600,4.0.0)' but it could not be found
  Cannot satisfy dependency:
    From: C/C++ Development Platform 12.1.0.202506041907 (org.eclipse.cdt.platform.feature.group 12.1.0.202506041907)
    To: org.eclipse.equinox.p2.iu; org.eclipse.cdt [12.1.0.202505191828,12.1.0.202505191828]

[jld01]

A CDT major version change occurs only when CDT's own APIs have changed in a way that may require changes in non-CDT features that consume those APIs. Ref: https://github.com/eclipse-platform/eclipse.platform/blob/master/docs/VersionNumbering.md

In the case of CDT 12.1.0, the dependencies of CDT on Eclipse platform APIs have changed, but changes to CDT's own APIs are non-breaking.

Does that answer your question? Please confirm.

[andrew-tram]

Partially. I do believe the move from CDT 12.0.0 to 12.1.0 introduces a functionally significant compatibility break for end users. Specifically, CDT 12.1.0 increases the required Eclipse platform version from at least 4.31 (could be earlier, but not sure, though org.eclipse.cdt 12.0.0 requiring org.eclipse.ui.intro;bundle-version="[3.2.0,4.0.0)",org.eclipse.ui.cheatsheets;bundle-version="[3.2.0,4.0.0)" would illude as such) to 4.36. While this may not constitute a breaking change to CDT's own APIs, it does break compatibility with the previously supported platform, which in turn breaks downstream adopters.

According to the Eclipse versioning guidelines, a minor segment change should capture externally visible changes, including "increased minimum Java version via the Bundle-RequiredExecutionEnvironment" and similar external shifts. I would argue that raising the minimum required Eclipse platform version falls into this same category; if not something more significant, since it can fully block installation.

From an adopter perspective, a change that renders a previously compatible CDT version no longer installable without upgrading the entire Eclipse platform is not a minor shift. That sort of disruption might merit either a major version increment or a clearer communication that a platform upgrade is now required.

But, I suppose my question boils down to - is the expectation CDT 12.1.0 requires Eclipse 4.36 or later?

[andrew-tram]

Following this - #1165

and https://bugs.eclipse.org/bugs/show_bug.cgi?id=536448

I suppose that answers my question as it suggests that CDT is now locking down its dependency ranges more tightly, making the platform alignment an enforced expectation rather than a soft recommendation.

[jonahgraham]

But, I suppose my question boils down to - is the expectation CDT 12.1.0 requires Eclipse 4.36 or later?

TL:DR - Yes.

@andrew-tram Sorry about the disruption to your workflow here.

Each version of CDT is only supported against the version of Platform it depends on. With tooling in Tycho we are now able to more easily able to update MANIFEST.MFs.

We needed to change CDT because of changes in Eclipse Platform that meant to support Eclipse Platform 4.36 we need to build against it. In particular #1159 (comment) tries to explain more about the why.

But perhaps we missed something here. Is there a minor version bump in CDT bundles that should have happened to make it clearer?

https://bugs.eclipse.org/bugs/show_bug.cgi?id=536448

I suppose that answers my question as it suggests that CDT is now locking down its dependency ranges more tightly, making the platform alignment an enforced expectation rather than a soft recommendation.

Yes - this is correct. There are subtle changes in the Eclipse Platform API that means in practice we cannot be forward binary compatible. i.e. we must run against a >= version of Eclipse Platform that we build against.

However, since Eclipse Platform itself does not actually follow Semantic versioning (at least not 100%) and CDT uses some Platform internals that aren't subject to Semantic versioning, it means that CDT really only is 100% guaranteed to work with the version of Platform it was built against.

For more info on platform's use of Semantic versioning, see https://github.com/eclipse-platform/eclipse.platform/blob/master/docs/ApiRemovalProcess.md in particular:

In general, removing a deprecated API does NOT cause the increase of the major version segment.