| Re: [epp-dev] Moving a package to Java 11 as requirement |
Let's do a thought experiment. I've decided to use Java 11 in EMF and have decided to change the BREEs as such. Is anyone else's opinion binding? Maybe the Modeling PMC's opinion would be, but I'm the lead and clearly I agree with myself. I don't think the Planning Council's opinion is binding is it? I see no rule stating that I'm not allowed to use Java 11 for my project and my right to determine my project's course is very important to me. In any case, I'm on the Planning Council, though with spotty attendance, and I could argue that they have no jurisdiction. I would also think that the Eclipse Packaging Project's opinion is not the least bit relevant to me personally nor to my project. After all, I have no binding opinion there, and if an opinion isn't binding, it follows that it has no real weight and is of little value. So in the end, from my project-centric view, everyone should consider themselves lucky to have EMF at all.
What problems would this cause? Nothing serious technically.
Just change the required Java version for all products and your
done. Get over it already.
I suppose the Planning Council could decide that some old version
EMF should be on the train instead, and the EPP can then just use
that old version. But then you'd all be on your own, without new
releases nor bug fixes, ever.
Clearly it would be better if I were sensitive to the community's opinions and needs rather than focused so much on what is and is not binding.
_______________________________
The issue of arguments for or against a higher BREE?
The arguments for are clear. We get to use the latest and
greatest Java language features and most current Java library
classes and methods. That's strongly compelling when considered
in isolation of all other considerations.
The arguments against are less clear.
Consider the packages page:
https://www.eclipse.org/downloads/packages/
The hint about needing Java 8 on bottom sidebar to the right
would need to mention more specifically the need for Java 11 for
some of the packages. No big deal, but would need attention.
Users launching a newly unpackaged package will be informed that
they need Java 11 (or the installer will inform them, though if
EMF changes the installer itself would need Java 11 not just Java
8). No big deal; the user will hunt down the right thing from
somewhere. A little worse is that users who install/update into an
existing installation will find their installation broken if it
was EMF involved, because nothing in the IDE will start without
EMF starting, or will find parts of the installation not working
for mysterious reasons. I suppose also no big deal when it's some
leaf component involved.
None of these consequences are ideal though and unfortunately we
have no statistics to indicate how much more likely a user is to
have Java 8 already installed versus Java 11 or higher already
installed. But clearly setting the bar higher will leave more of
the community below the bar while leaving the bar where it is now
is most definitely less disruptive.
On Sun, Mar 1, 2020 at 8:28 PM Mickael Istria <mistria@xxxxxxxxxx> wrote:
On Fri, Feb 28, 2020 at 9:27 AM Daniel Megert <daniel_megert@xxxxxxxxxx> wrote:
No, it is not OK for the same arguments mentioned before.
Can you please remind those arguments? I'm curious about which ones apply to typical Corrosion target audience.Also -and without any offense but more to clarify who has influence/authority on EPP project as it's facing a transition-, I'm curious about whether your opinion as Planning Council member but non-EPP committers is to be considered as binding. WDYT?
Planning Council has no bigger right over EPP (compared to any other project) to say whether EPP project allows some of its deliverables to require Java 11. It was specifically discussed at the last Planning council and we agreed on that https://wiki.eclipse.org/Planning_Council/2020-02-05#Notes . This is a decision which should be driven by the EPP project committers together with the not-yet-elected lead.
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/epp-dev
--
Alexander KurtakovRed Hat Eclipse Team
_______________________________________________ epp-dev mailing list epp-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/epp-dev