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