Skip to main content

[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,

I think you are jumping to premature conclusions here.

Before going into details, if you have evidence that everything outside the compiler is unaffected by legal restriction, please show us. And by evidence I mean more than a bit of hand waving from your own reasoning.


Until that is provided, I believe that *any commit* relating to an unreleased Java version is not allowed on master, from which soon a release will be created, and where we don't want the disclaimer
  "This [...] is made available for testing and evaluation purposes only.
   The code is not compatible with any specification of the JCP."


In the meanwhile we might as well take stock: Are we actually done with support for released Java versions, or should we rather spend our energy on making support for Java 23 really great? This can be done without any legal risks or process concerns :) And we could even join forces rather than dividing the community - but maybe here I'm arguing in a selfish way myself :)

Stephan

Am 17.01.25 um 12:09 schrieb Mickael Istria:
Thank you all for your answers.
I read that most of the technical or legal or process concerns seem to apply mostly for the compiler bits such as the grammar. My selfish motivation is the following: with the Javac backend for JDT, we may soon want to work on support for new Java version features at DOM level and beyond (eg core.manipulation) and have them in master ASAP, and if we're to contribute for example some refactorings targeting next Java version, we'd rather not have to deal with branches and feature patches when contributing to JDT. But it seems both are not contradictory: this would still be possible to put work regarding DOM and manipulation for next Java version in master. So basically, let's keep things as it, and when we're to contribute stuff for DOM or Manipulation for next Java, we'll do it on master anyway. This should work for everyone without really changing anything. We may revisit this discussion when we have such "DOM for next Java" contributions coming in.
Cheers,

On Thu, Jan 16, 2025 at 4:00 PM Stephan Herrmann <stephan.herrmann@xxxxxxxxx <mailto:stephan.herrmann@xxxxxxxxx>> wrote:

    Now to the question which problem we are trying to solve:

    For a moment let's not talk about technical or legal issues, but about people.
    Obviously we all want as many good people working on JDT as possible :)

    But I have difficulties recalling the "dozens of people" who have tried to work
    on unreleased java features and have gone away due to complexity of branching.
    If I think long enough I could remember one person who might possibly match
    this
    description, his name is Mickael Istria :)

    So either I just didn't notice others suffering the same fate, or we should
    simply switch to helping Mickael to learn working in the branch :)

    More broadly speaking, I think the interest in unreleased Java versions has
    drastically dropped by the time when Oracle switched to the current release
    cadence. Back at the time of Java 8 and Java 9, of course there was great
    anticipation of the next big thing, both at the JDT side and even more on the
    side of users, eager to work with the new version even before it was released.
    My guess is that nowadays people are happy to play with the recently released
    features, which will still be new to most of them perhaps several releases
    back.
    So why look at the one additional small set of changes that hasn't been
    released
    yet? Does JDT have all the IDE features we could wish for, regarding java
    versions up-to and including 23? I don't know who's working on that, but there
    might be enough enhancements to be done even on master?

    That said, I'm all in favor of raising more public awareness, both for testing
    Y-builds as well as for patch releases.

    Another people-aspect is collaboration between JDT and releng. Perhaps the
    perception of problems result from my requests for releng help for the branch
    every now and then? But don't I ask for releng help for master much the same
    way? :) -- In this regard even just a single person can make the difference. In
    the past Sravan was one such person. Ed Merks has always been a solver of all
    kinds of problems (and I don't recall him complaining about the branching).
    Currently Hannes Wellmann has done great contributions in this area, and please
    excuse if I forget someone else in this category. So perhaps we could just let
    releng people speak for themselves here? Perhaps Aleksander is the one being
    asked for help more than he likes? It would be only fair for him to say so.

    While the grass could always be greener, and surely not everything is sunshine
    and roses, perhaps we don't even have a problem of a severity that motivates
    any
    major changes? - Other than: more contributions! :)

    best,
    Stephan

    Am 15.01.25 um 09:51 schrieb Mickael Istria:
     > 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



--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat <https://developers.redhat.com/>



Back to the top