From:
jdt-dev <jdt-dev-bounces@xxxxxxxxxxx> on behalf of JAYAPRAKASH ARTHANAREESWARAN via jdt-dev <jdt-dev@xxxxxxxxxxx>
Date: Wednesday, 15 January 2025 at 11:19 AM
To: Eclipse JDT general developers list. <jdt-dev@xxxxxxxxxxx>, Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
Cc: JAYAPRAKASH ARTHANAREESWARAN <jarthana@xxxxxxxxxx>
Subject: [EXTERNAL] Re: [jdt-dev] About Y-Builds (was Re: 4.35 Y-Build: Y20250111-1000 - BUILD FAILED)
Mickael, If we are unable to answer Stephan’s first question [1], then everything else becomes a moot point. Nevertheless, let me throw in another factor: The Java
version release spans two eclipse releases let’s say E1 and E2. If we are going
Mickael,
If we are unable to answer Stephan’s first question [1], then everything else becomes a moot point.
Nevertheless, let me throw in another factor:
The Java version release spans two eclipse releases let’s say E1 and E2. If we are going to publicly say that E1 is going to include Java 24 changes, what exactly do we promise? Or we just don’t care at all?
Or the developers are supposed to factor in the half-way E1 milestone and plan their changes accordingly? Fact of the matter is, the Java release generally occurs even after E2, so, we can’t even promise anything for E2. And what happens during the quiet period
between the builds, however short it is? This is a classic case that warrants a different branch and a merge strategy. And yet, we are thinking of developing in the same branch, even at the cost of convoluted code with switch, flags and what not. I can’t think
of a reasonable answer to any of these questions. But then, may be, I am biased
😊
Now that the Y builds from BETA branch have been made public, with more frequent merges and builds, the
Y build can be made as good as I build. So, the few adopters who care about, can in fact take the Y builds
and experiment.
Regards,
Jay
[1] >
* get public confirmation from Eclipse Foundation legal staff that what you plan will not invite Oracle to file a multi million dollar law suite.
From: jdt-dev <jdt-dev-bounces@xxxxxxxxxxx>
On Behalf Of Mickael Istria via jdt-dev
Sent: 14 January 2025 12:05
To: Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
Cc: Mickael Istria <mistria@xxxxxxxxxx>; Eclipse JDT general developers list. <jdt-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [jdt-dev] About Y-Builds (was Re: 4.35 Y-Build: Y20250111-1000 - BUILD FAILED)
On Mon, Jan 13, 2025 at 10: 00 PM Stephan Herrmann <stephan. herrmann@ berlin. de>
wrote: * ask people who do work in BETA branches, how easy it would be to ensure that every little change that is currently done in the branch can be safely
Gathering feedback from experienced ECJ developer was actually the initial intent of this thread.
So I'm asking: could feature switches work for ECJ ? What would seem the harder (excluding the cost of the change itself) for ECJ developers: the rebase/merge process with branches or using feature switches?
As for less core contributors (ECJ testers, JDT Manipulation, JDT UI...), I'm quite certain that just having feature switches will make working towards newer Java much more efficient, as this would becomes just flags to activate rather
than dealing with patch features, which is often causing trouble.
