Plugin dependency should always contain a version range about cdt

[ruspl-afed]

What version range do you have in mind?
This is in theory good requirement, but in practice it implies that someone do revisit all the plugins relatively frequent and does care about updating the ranges. Is this really the case for the modern times?

[Torbjorn-Svensson]

Well, the problem is that without a range and changing the BREE, there is nothing that downstream can do to ensure that the right plugin is installed.
I don't think it's a good model that ever downstream vendor should look though each and every "internal" dependency that a certain plugin has, it should be enough to just say that I want this particular CDT feature and it should be just that and nothing else. With the current way, you get the CDT feature and some other hang-around plugins, but at random times, you get a version that is incompatible with the rest of the product and then nothing works. No warning, no error, no nothing to the user except that the plugins refuse to load.

In my world, this is a serious break of the contract to the downstream vendors/users.

[ruspl-afed]

Well, the problem is that without a range and changing the BREE, there is nothing that downstream can do to ensure that the right plugin is installed.

Platform updgraded to Java 11 without changing major version and most probably will repeat this trick after move to Java 17, so version range will not help a lot.

but at random times, you get a version that is incompatible with the rest of the product and then nothing works

This looks more like a p2 issue: p2 has all the information to analyze EE & BREE and reject to install.

[akurtakov]

Platform updgraded to Java 11 without changing major version and most probably will repeat this trick after move to Java 17, so version range will not help a lot.

Just FYI this is documented and expected behavior for long time now https://wiki.eclipse.org/Version_Numbering#When_to_change_the_minor_segment .

[ruspl-afed]

Thank you for this link @akurtakov , no idea why I was sure that BREE upgrade is API breaking change.

[jonahgraham]

This sounds like a p2 bug - i.e. that installing Bundles with BREE > than running Java should not be allowed. This is going to affect much more than just CDT as other things (like tracecompass, lsp4e, tm4e) also all have (or will soon have) BREE of Java 17, but no major version change.

[Torbjorn-Svensson]

This sounds like a p2 bug - i.e. that installing Bundles with BREE > than running Java should not be allowed. This is going to affect much more than just CDT as other things (like tracecompass, lsp4e, tm4e) also all have (or will soon have) BREE of Java 17, but no major version change.

I think you are referring to the old discussion in ticket https://bugs.eclipse.org/bugs/show_bug.cgi?id=483383.
I do agree that it's hard to get this right for every possibility, but I think the major problem is that there is no validation that there will be a problem after restarting Eclipse if the BREE is higher than an available JRE.
I think that the follow use-cases should be supported:

1. The user upgrades to a new version, or installs a new feature, with the same BREE requirements.
   This should be allowed without any issue.
2. The user upgrades to a new version, or installs a new feature, with a higher BREE requirement.
   This should only be allowed if the upgrade also pulls in a new JRE that meets the new BREE requirement. If it does not fullfil the required BREE, then the user should at least be prompted about the implications of completing the upgrade.

I know that there is the checkbox in the Window -> Preferences -> Install/Update, but checking that checkbox will have the consequence that it's not possible to upgrade to a new version that do require a newer version of the JRE even if the new JRE would be installed in the same p2 operation.

When I wrote this issue, I was not aware that it was considered a "minor" bump for the BREE change. I personally think this is a mistake as there is simply no way to defend against the unwanted changes as a consumer of a bundle.