| Re: [jdt-dev] About Y-Builds (was Re: 4.35 Y-Build: Y20250111-1000 - BUILD FAILED) |
On Wed, Jan 15, 2025 at 6:49 AM JAYAPRAKASH ARTHANAREESWARAN <jarthana@xxxxxxxxxx> wrote:
If we are unable to answer Stephan’s first question [1], then everything else becomes a moot point.
We will get an answer whenever we ask; but I'd rather ask only after this discussion, as some technical blockers might be unveiled.But for the rest of discussion, let's assume the answer from legal would be that we can have feature flags controlling unspecified-yet compiler behavior (and some UI elements to control them).
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?
I don't think anyone has suggested to claim public support in E1. What I'd suggested is that in E1, there would be some flags such as `-Djdt.jepXYZ` existing for testers to enable the current support for the upcoming Java feature; but some guards to disable such features by default.Then only when Java gets released and JDT support is complete enough, instead of a merge, we just remove those flags in the code to enable support by default. And this would happen in E2.So I don't think BETA branch vs feature flags do change anything regarding the timeframe when next Java support is GA.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.
Branches could still be used for individual development when necessary. The difference is that branches would be used "when necessary" (eg quiet period) instead of "for the whole development of next Java version".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 😊
Indeed, the code would be more convoluted but the process to develop/contribute/merge would be way less convoluted.My perception is that the process to contribute to next Java version in JDT is really difficult and has thrown dozens of people away. Indeed, there are a few example of people working on JDT for years or on Eclipse Platform many hours a week (and being paid for that) who can deal with this convoluted process efficiently enough for them, but there are some who just give up trying to contribute to next Java version because this process is too complicated and makes them less efficient and less successful. And I suspect this is more people giving up than peopel actually contribution, and that "mainstreaming" the process would keep some more people around and that it would be worth the cost of a few `if (Boolean.getBoolean("jdt.jepXYZ")` here and there.But I'm biased too.So, the few adopters who care about, can in fact take the Y builds and experiment.
Well, that's one issue I'm trying to address, and IMO 1 issue that should be the priority for JDT as a project if it wants to remain viable on the long run: how come there are so few adopters who care about? I think the BETA branch is one bit of a cause here.Cheers