Update bree recommendation

[vogella]

No description provided.

[vogella]

@akurtakov @HannesWell this one is actually a change in the BREE update recommendation, before this we recommend NOT to update if a required plug-in had a higher BREE, but these days I think we even show a warning with in PDE and in the past updates such plug-ins to the same BREE:

Let me know if you disagree with the new recommendation.

[akurtakov]

Sounds good to me.

[merks]

I always found the warning that I should update the BREE to be annoying, unhelpful, and misleading. I think technically one should update the BREE if the minimum version of every dependency has a higher BREE because only in that case is it not possible to install your bundle into an environment with such a low BREE. But there is nothing helpful to figure that out, and more often than not, the lower bounds are wrong. EMF for example, installs into luna, so I will not increase the BREE. But that's what the removed content is trying to explain, so I don't see value in removing those insights as if they no longer matter.

The only reason one absolutely must increase the BREE is because the .classfiles cannot work in a lower environment or you use classes/method not available in the lower environment.

[vogella]

@merks how would you run EMF on a low BREE if ONE of your MINIMUM requirements require a higher Java version?

I think you describing the case in which you keep your minimum requirements super low so that you still can run on a low Java version.

[merks]

@merks how would you run EMF on a low BREE if ONE of your MINIMUM requirements require a higher Java version?

I though I worded my statement carefully draw attention to exactly this case.

I think you describing the case in which you keep your minimum requirements super low so that you still can run on a low Java version.

No, I keep the requirements super low so that folks restricted to used such lower/old things (requirements) can continue to get updates from EMF. Of course it would be easier for me to not care and it would be more cool to use the latest language features. But EMF's value comes more from being reliable, bug-free, and stable, than from being new and cool. That's a much different story than for the Platform where the opposite is the case!

I'm not sure @HannesWell is very available to provide feedback while on vacation...

[github-actions]

Test Results

   291 files  ±0     291 suites  ±0   1h 7m 50s ⏱️ - 2m 51s
 3 526 tests ±0   3 468 ✅ ±0   58 💤 ±0  0 ❌ ±0 
10 875 runs  ±0  10 698 ✅ ±0  177 💤 ±0  0 ❌ ±0 

Results for commit 7611627. ± Comparison against base commit d89028d.

[vogella]

@merks how would you run EMF on a low BREE if ONE of your MINIMUM requirements require a higher Java version?

@merks how would you run EMF on a low BREE if ONE of your MINIMUM requirements require a higher Java version?

I though I worded my statement carefully draw attention to exactly this case.

I don't think this is possible.

For example, if EMF would require a version of a plug-in A which requires Java 17, how would you run EMF on a Java lower than 17?

I think you said: I will not do this, I will only require A in a version that also requires this lower Java version. But that is not the case we discussing here, of course if you do NOT require a version that requires a higher BREE, you still can run on the old version.

[laeubi]

For example, if EMF would require a version of a plug-in A which requires Java 17, how would you run EMF on a Java lower than 17?

If I require an API in version [1...4) and version one of the API requires Java 8, Version 2 requires Java 11 and Version 3 requires Java 17, and my bundle requires EE8 it can run with all these version, of course I can never use any never API in my bundle then.

[vogella]

and my bundle requires EE8 it

Yes, in this case you DO NOT require a version of a plug-in A which requires Java 17.

The documentation update is for required dependencies, not for other plug-ins that also exists.

[laeubi]

and my bundle requires EE8 it

Yes, in this case you DO NOT require a version of a plug-in A which requires Java 17.

The documentation update is for required dependencies, not for other plug-ins that also exists.

Please read carefully, my bundle can Require-Bundle (or better import package) 'A' with a version range and in this range there can be versions of A that require a lower BREE so my Bundle, even it depends on A can run in a lower BREE if it is installed in a system that uses an older version of A but a newer version of EMF...

[vogella]

and my bundle requires EE8 it

Yes, in this case you DO NOT require a version of a plug-in A which requires Java 17.
The documentation update is for required dependencies, not for other plug-ins that also exists.

Please read carefully, my bundle can Require-Bundle (or better import package) 'A' with a version range and in this range there can be versions of A that require a lower BREE so my Bundle, even it depends on A can run in a lower BREE if it is installed in a system that uses an older version of A but a newer version of EMF...

The documentation header is: ## I have prerequisites that require version X to run, so shouldn't I require version X too?

[HannesWell]

and my bundle requires EE8 it

Yes, in this case you DO NOT require a version of a plug-in A which requires Java 17.
The documentation update is for required dependencies, not for other plug-ins that also exists.

Please read carefully, my bundle can Require-Bundle (or better import package) 'A' with a version range and in this range there can be versions of A that require a lower BREE so my Bundle, even it depends on A can run in a lower BREE if it is installed in a system that uses an older version of A but a newer version of EMF...

The documentation header is: ## I have prerequisites that require version X to run, so shouldn't I require version X too?

The question is indeed not absolutely clear so you are both right, although Christoph's answer is more precise.

In general, I don't think we should make absolute recommendations. Instead we should explain the implications and what a user should consider when making a decision (obviously the most important implication is that the BREE defines the minimum required JRE version to execute that version of the bundle).

In the end it is probably a question of how hard one wants to try to lower the BREE (assuming everything becomes better and easier with never Java versions). And it is indeed not well invested effort to try hard to be lower as the oldest required versions of all dependencies.
Although theoretically they could lower their BREE, but is very seldom (I don't know a relevant case).

What is definitely wrong is the statement about APIs. Even if one uses types from newer versions only internally, one has to use a supporting JRE.

[akurtakov]

I consider this proposal being clearer than the current wordy one. Is anyone against landing this one?

[vogella]

I consider this proposal being clearer than the current wordy one. Is anyone against landing this one?

"This proposal" is the change in the PR?

[akurtakov]

I consider this proposal being clearer than the current wordy one. Is anyone against landing this one?

"This proposal" is the change in the PR?

Yes

[vogella]

Merging based on @akurtakov. I also think the shorter statement reflect better the current reality.
The original concerns raised should be covered by the new statement.

Please create follow-up PR in case you see a need to do so.