Note: "Inactive" refers to Strategic Members we have not heard from in a year or so, and have been unable to convince to participate. Those members can become active again at any time. Contact David Williams if questions.

Juno Release Planning

Good discussion with good feedback (positive and constructive), though still not much known in terms of concrete plans of (sub) projects, so would be good to get that, if possible, by June. But, others were quick to point out, probably won't know much about Juno plans for months to come, not by next month.

Concern was mentioned the proposed plan still reads with a little too much emphasis on 3.8, as though 4.2 wasn't ready yet.

Perhaps wording could be improved ... perhaps to change emphasis to "state concrete plans for 3.8 early", supported or not, tested or not, respond to bugs or not, same function or not in both streams, etc., so adopters and downstream projects know what to expect? And to include better wording as to the purpose ... "The Planning Council encourages, as good Eclipse citizens, we should support adopters that can not make the transition completely to 4.x stream yet". Or similar (that is, explicitly, it is not because 4.2 is not ready).

It was mentioned, that some projects, such as the Platform's JDT, might end up "splitting streams", not even necessarily because of the split workbench, but they might tie down 3.8 as a maintenance-only stream, and put new feature/functions in 4.x only. They haven't decided that yet, just mentioned it as a possibility. [And, if anyone is wondering, the 3.x stream would contain the Java 7 support, since that's largely done already in 3.x stream.] It was pointed out this might have big impact on downstream projects, such as Web Tools ... unclear if downstream projects would have to split streams in such cases, or double-up on testing two version of JDT, as one example, and those downstream projects might have to pick one or the other to focus on (and it might not be 4.x). Put another way, if there is a potential split stream for every project, then the complexity would grow quite large. Maybe too large and complex to cover in our Simultaneous Release Plan? At some point, we might have to say, we as the Planning Council are only concerned with one stream, and only those that want to participate on that stream, ... and any other configuration is outside the scope of Planning Council's yearly release. Just a possibility.

It was also mentioned that early testing, of Indigo stream and "a large IBM adopter product" has gone well on 4.x stream so the Platform team has high confidence in compatibility layer.

There was, still, a general feeling that "4.2 as primary platform" would be a fine to great plan. More a question of what to do/say about 3.8. The council was reminded that 3.8 was deemed important by some members, not even necessarily for their own stuff, but sometimes there are dependencies or add-on tools that are outside Eclipse and outside members control that they still want to support or work with. I'm not sure we'll ever know concretely the degree of that? And, it is even unclear if that's a theoretical concern, or if there are already specific, known cases?