Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] Meeting this Wednesday
So... I don't see from the minutes what the decision was regarding Oxygen releases:

* slipping June release to late July, then a September release
* a June release, then a July "JDK update" release, then a September release
* a June release, NO mid-summer "JDK update", then a September release

Pros/Cons seem to be:

* do June release because we're already testing with JDK 9 (beta) support, so we should be ready(ish)
* don't do June release because we'll need to do a July release anyway and EXTRA releases take effort / cost money & time

* do June release because not everyone can commit to doing work over the summer to prepare for a July release
* don't do June release because we MUST have a fully-supported story & a release on July 27 or else risk losing market share

* do June release because we've been doing time-boxed releases for over a decade and we rule at consistent releases
* don't do June release because "just because we have done it that way, doesn't mean we SHOULD"

* do July release: bad because extra cost
* don't do July release: bad because making users wait until September makes us look "slow to market"

Sounds like the best solution here is to do three releases: June, July, September... and let projects opt-in to the July one only as needed (eg., JDT, WTP might be the only ones with required updates).

We could also simply take a "wait and see" approach -- plan for June and Sept, and if needed, add the July release too. 

But from Wayne's comments, we NEED the July release from a marketing perspective.

So... maybe that's the answer: do three releases, even if the July one is just a lightweight "summer refresh" release that only updates a few features/plugins.

Thoughts?

Nick


On Wed, Mar 1, 2017 at 1:32 PM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:

On the call today, Tom stated that the launchers will be updated to launch properly on Java 9.


Tom, please correct me if I've misrepresented what you stated.


Thanks,


Wayne


On 01/03/17 04:35 AM, Ed Merks wrote:

I'm not sure the current of being able to run with Java 9, let alone supporting its features well in JDT:


  https://bugs.eclipse.org/bugs/show_bug.cgi?id=493761


I assume this must be fixed in a general way that works regardless of whether Java 9 is actually used or not and regardless of the JVM implementation provider.  Is it hopeful that this will be addressed in time that we may all test the state of Java 9? 


Does it really make sense to plan the whole release schedule around this assumption?  And as Marc suggests, is planning a release during the high vacation season a good plan?



On 28.02.2017 18:51, Marc Khouzam wrote:

+1

Considering the dates are so close between Oxygen.0 and Java 9,

I think having an extra release is more hassle for adopters than it is worth.

So waiting for Java 9 is a good plan for Oxygen.0.


One drawback I see is that more people will be on vacation at that time,

but with proper planning, it should not be a problem.


Marc


From: eclipse.org-planning-council-bounces@xxxxxxxxxxx <eclipse.org-planning-council-bounces@xxxxxxxxxxx> on behalf of Martin Lippert <mlippert@xxxxxxxxx>
Sent: February 28, 2017 3:47
To: Eclipse Planning Council private list
Subject: Re: [eclipse.org-planning-council] Meeting this Wednesday
 
+1 for moving the Oxygen.0 release to the JDK9 release date.
Would make things for adopters of that release easier, too.

Cheers,
-Martin



> Note that I've added a biggie to the list: with all the talk about having an extra release to coincide with the Java 9 release, we've neglected to ask why we need a release in both June and July. The Java 9 release date (which by all accounts is pretty stable) is about a month after our planned Oxygen date. Is there any reason why we shouldn't just move the Oxygen.0 date (other than "we've always done it that way") ?
>
> Feel free to answer here. It would be great if you can come to the meeting armed with an answer to that question.
>
> See you on Wednesday.
>
> For all phone lines: Participant conference extension: 710 then enter pin 35498
>
> North America (toll free) 1-866-569-4992
> Germany (local call anywhere in Germany) +49-692-2224-6059
> France (local call anywhere in France) +33-17-070-8535
> UK (toll free) 0800-033-7806
> Switzerland (local call anywhere in Switzerland) +41-44-580-2115
> SIP clients: call 710@xxxxxxxxxxxxxxxxxxxx, then enter pin 35498.
> Wayne
> [1] https://wiki.eclipse.org/Planning_Council/February_01_2017
>
> [2] https://wiki.eclipse.org/Planning_Council/March_01_2017
>
> --
> Wayne Beaton
> @waynebeaton
> The Eclipse Foundation
> <ConvergeLogo_Transparent.png>
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
eclipse.org-planning-council Mailing List Info Page
dev.eclipse.org
Mailing list for private discussions amongst members of the Eclipse Planning Council. Using eclipse.org-planning-council To post a message to all the ...


>
> 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.

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@eclipse.org
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
eclipse.org-planning-council Mailing List Info Page
dev.eclipse.org
Mailing list for private discussions amongst members of the Eclipse Planning Council. Using eclipse.org-planning-council To post a message to all the ...



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.


_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@eclipse.org
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

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.



_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@eclipse.org
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

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.

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
Eclipse Converge

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@eclipse.org
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

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.



--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

Back to the top