[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-dev] About Y-Builds (was Re: 4.35 Y-Build: Y20250111-1000 - BUILD FAILED)
|
Mickael,
As an engineer I know how to solve technical issues like working in a branch.
It's not rocket science. Recently Hannes made great improvements in making
things smoother than before [1]. And we (JDT) have even adopted the
responsibility for P-Builds. A little hiccup here and there is part of our
business, isn't it? So let's not exaggerate on the complexity of working with a
branch.
If you have legal expertise I'd be happy to hear how we can convince Oracle that
releasing support for unreleased Java versions is fine. Without such legal
advice I don't see value in this long running discussion.
Stephan
[1]
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/2625
PS: While I have you, have you seen
https://github.com/eclipse-jdt/eclipse.jdt.core/issues/3552 ? Perhaps this
additional build is more complexity than we need?
Am 12.01.25 um 19:48 schrieb Mickael Istria:
Hi,
I'm sorry for highjacking a bit here, but the temptation is too big ;)
The Y Build are by nature making things much more difficult: it's a dedicated
separate branch (requiring some branch switch, dedicated -and highly tweaked-
builds, particular version numbering, effort in backporting main changes into
the Y branch, and then effort in merging back content of the Y branch into I
Builds...). This is really hard to follow and use.
I don't think the "risk" of directly implementing next java version support
directly in master/I-Build is that high. If there are technical or even legal
concerns, some feature switches (eg system properties) can be set up to guard
the risky bits. Feature switches are now a proven pattern in long-living
software development. They can provide ability for standard users to not be
bother with bleeding-edge and immature features, while allowing more curious
users to try them. They make that the difference with and without the feature is
"only" a software behavior one and not so much additionally a releng/deployment
one. Everyone gets the same bits of software, tests and reports issues against
the same bit of software.
So IMO, rather than improving/fixing the process for Y-Builds, and in the light
of frequent drop of manpower on Eclipse releng, it might be a good time to
consider what are the blockers against directly working in I-Builds with feature
patch or anything else that could work, and maybe get rid of the Y-Build.
FWIW, and Alex will correct me if I'm wrong, our Red Hat team for example is
unlikely to invest in getting the Y-Builds process work better; while we've
constantly committed in getting JDT I-Builds constantly going smoothly and
smoothlier. Maybe we're the only one going with that support pattern (we can
sometimes be strong on some principles, but we're as everyone driven by manpower
optimization), but if not, then it can mean that in the currently state Y-Builds
are currently harming the JDT community as the process makes it less motivating
and profitable for potential contributors to participate.
Cheers,
