Juno/Initial Working Plan
This document is just to document some working notes towards the Juno Plan ... not the official plan.
These are the proposed high-level dates for Juno deliverables. They follow same "pattern" as previous years.
- Release: June 27, 2012 (fourth Wednesday)
- SR1: September 28, 2012 (fourth Friday)
- SR2: February 22, 2013 (fourth Friday)
For Juno, Eclipse 4.2 will be the primary workbench, but all (participating) projects will support and maintain a 3.8 based deliverable.
'Primary workbench' means Eclipse 4.2 will be the primary workbench that (participating) projects build against, and test, and will be provided in the common repository, and EPP packages. In all cases, "4.2" means "4.2 plus compatibility layer". That is, no one is required to split streams, use 4.2 workbench "native" APIs or exploit anything specific to 4.2. Of course, projects can if they want to (within the Assumptions, below) but there is no requirement to exploit 4.2 directly.
'Support and maintain a 3.8 based deliverables' means that (participating) projects, at a minimum, agree to continue to provide a deliverable that can be used with 3.8 workbench. In most cases, we hope, this is the exact same deliverable used for the 4.2 based deliverable. This would be true for projects that do not use 4.2 specific API and simply rely on the compatibility layer. But for projects that want to exploit something new in 4.2 workbench ... that is split streams and have one specific to the 4.2 workbench prereq ... then they would still be expected to provide something adopters or upstream projects could use for 3.8-based installs. When there are two separate deliverables, the 3.8-based maintenance version might simply be Indigo SR2, at a minimum. But, even then, there might be cases where versions ranges have to be adjusted, or bugs fixed due to changes in 3.8 (since Indigo SR2 will be built and tested with Eclipse 3.7.2). Those are the minimum assumed deliverables. Naturally, projects may do more if they have desire or reason to, but the goal is to allow adopters an extended "transition" period to 4.x, if needed, where things will still work, in good form, using 3.8 based prereqs. For projects that do have "two deliverables", the 3.8 based one would be available on their own download sites and their own project's software site repositories, not the common repository.
While we want to allow projects to split streams, if they want or need to do so to exploit some new feature in Eclipse 4.x, some care and careful coordination is required. We assume no "low level" projects introduce split streams in such a way that would require all dependent projects above them to also split streams. This could easily lead to "double work" for many people, which is not practical. Some projects may have "split streams" but keep their API the same. This would allow dependent projects to still have just one stream, assuming they use only API, but even then, they might have to do "dual testing" to make sure both installs work as expect, so might be some increase in effort. The point is, care and coordination is required.
Plan roll-out and point of no return
We need to follow a process of evaluating this proposal, making sure there are no "blockers" that prevent it becoming our final plan.
The first step is to "publish" this plan for feedback. We'll incorporate feedback received, from projects, or adopters, in our May meeting and then again in our June meeting. At that point, as Indigo releases, we'll consider this "proposed plan" to be our "initial plan" for Juno.
To move from "initial plan" to "final plan", we will simply follow our plan and re-evaluate each milestone of Juno, that is for M1, M2, M3, and M4. Naturally, we expect confidence to grow incrementally each milestone, but M4 (in mid-December) will be assumed to be the point of no return. If no issues are found that prohibit this "4.2 is primary" plan, then it will be considered final after M4, mid-December, 2011 (which is the normal time for the "final plans" for our yearly June releases).
This cycle differs a little from previous cycles, since it assumes projects and adopters do plenty of early testing with those early milestones (and/or early 3.8 based installs) to make sure it is a valid plan fulfilling their needs. Typically, many projects will be busy with Indigo maintenance during this same period of time, so it does take some commitment to also do the early Juno work if there are any concerns about implementing this plan.
Q: Given that 4.2 is "primary" and used in repository and EPP packages, what is the nature of the "support 3.8" requirement? Can it really be said to be required?
A: It would not make sense to say "Even though you support 4.2, you can not be in 4.2 based repository, since you do not support 3.8". Hence, 3.8 support is technically a "should do". But, if not obvious, the plan would make no sense at all if "low level" projects decided they would opt out of supporting 3.8. Hence, there is an aspect of "must do" for at least those low leve projects which others depend on.
Adopters could maybe simply use Helios SR2 based bundles in their adopting project or products ... but, the expectation is that any blocking or critical bugs open against 3.8 preventing that kind of use would be accepted as valid. (For examples, if someone has an overly narrow version pre-req version range).
Put another way, since 3.8 not used in repo, or EPP packages, it would be hard to know if someone was not maintaining 3.8 compatibility ... would only show up from adopters or users that were "building their own" 3.8 based installs.
This would be a good reason to improve our "aggregation build" to produce a 3.8 based repository ... even though it would not be "delivered" or formally used. It would spot incompatibility issues early, at least. This would also be a value-add service to those adopters that needed 3.8 based builds, since then there would exist a "specification" of what goes into a 3.8 based install. Ideally it could be done with a sort of "incremental" build-aggregation-contribution files, so only differences would have to be listed.
This section is to list projects that already know if they have to split streams, and what effect that might have on downstream adopters.
|Mylyn||Mylyn will have to have "split streams" as they do now, for 3.7 vs. 4.1, but their API will be unchanged, so adopting projects do not necessarily have to split streams.|