Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Kepler J8 Release

How about just - No. It's a lot less work.

>From my understanding, Java 8 is likely to have a few updates in the coming days. It's early adopter still and for those adopters, it's pretty easy to install Java 8 support into Kepler. I'm not sure I agree with the sentiment on cross project, nor how wide a concern it really is.

Sent from my BlackBerry 10 smartphone on the Rogers network.
From: David M Williams
Sent: Sunday, March 23, 2014 9:27 PM
To: Eclipse Planning Council private list
Reply To: Eclipse Planning Council private list
Subject: Re: [] Kepler J8 Release

This will take some time, just to think through, and discuss with others.

I suggest we discuss at our next "first Wednesday meeting" (April 2) to decide what Planning Council's position is on this.

Thanks for raising it here.

In the mean time, I will leave a few thoughts in the form of questions:

Can we clearly state "what problem we are trying to solve"? Can we clearly state what benefits this would have?
More specifically, is this to benefit adopters? Is its purpose to get more feedback before Luna is released?
How much of the benefits could be obtained by simply having a wiki page that explained "who's provided Kepler SR2 patches" (and, providing a list of "patch URLS")?
My intuition is that your two month estimate is low, and that the best time to do a high quality SR3 would be after Luna ... and don't forget, any "post Kepler" work done now, will mean less work done for Luna (and Mars) ... and if that is the case, is it valid to have an SR after Luna? or does that put it into "LTS space"?
Would we be setting expectations too high? I know that even now, what is in the "JDT/PDE patch for Kepler SR2" is not as functional as what is in Luna I-builds (in some minor ways, right now, but would expect that to grow) so would the community think a Kepler SR3 have the same Java 8 support as Luna? And then be disappointed to learn that wasn't the case?

I have a more open mind than my questions might suggest ... but these are sincere questions I've not seen addressed (admittedly, some may have been, and I skim read too much).
And, I won't speak for Markus, but think you can take it as a good starting assumption that I won't be involved with the "aggregation work" -- I get little enough sleep as it is.

Thanks again,

From:        Ian Bull <irbull@xxxxxxxxxxxxxxxxx>
To:        "" <>,
Date:        03/23/2014 05:04 PM
Subject:        [] Kepler J8 Release
Sent by:

There has been a discussion on the CrossProject ML about a Kepler Java 8 release. If there is some, non-null segment of our community that this would help, I don't think we should completely ignore this request. However, I don't want to overstep my bounds, so I thought I would raise this here first.

Dani gave a good summary of why we should not "simply" (big air quotes there) release an SR3. Because of the changes required to the JDT, there is a good chance that this release is less stable than SR2, and while we have been discussing the reality that SRs are not more stable, the JDT + Platform is different. If this idea did go forward, I think a separate release 'Kepler J8' would be required.

Here is a draft response: 

If we are serious about moving forward with a J8 release for Eclipse, someone in the community will need to put a concrete proposal together. The proposal should cover:
1.        I assume this will also include a SimRepo as well as packages. Most of this repo should just be Kepler SR2, but we need to decide what updated plugins should be included (JDT for sure, maybe WTP, M2E, etc...). We need a list of updated plugins, and a +1 from the projects that they want their plugins included.
2.        Obviously some of these components have not been 'released' yet. Release reviews will need to be organized (let's not assume the projects will do this).
3.        We probably don't need to spin every package (CDT?, Modeling?), so we need to decide which packages to build.
4.        A list of resources, who will coordinate this, aggregate the repository and build the packages. Let's not assume David and Markus will have the time to do this.
5.        A QA / Sign-off process. Who is going to QA the packages, and what platforms will we support.
If someone puts a proposal together that addresses these points (and are capable of providing the resources to pull this off) would we be ok with it? It would also be good to put a date on this. If this work will take 2 months, bringing us to late May, is this still valuable?

Thoughts? Is this worth discussing? Or should we just stall long enough and let Luna leave the station ;).


R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 | _______________________________________________ mailing list

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

Back to the top