Indigo/HowToAddress37And41Platform

This page is to list plans, questions, policies, use-cases, and recommendations for how to approach the 3.7 versus 4.1 platform in the Indigo release.

Note that this is a "rough notes" page, to serve as a strawman statement, to assist the Planning Council in flushing out these issues and will be updated as questions answered, new issues listed, and possibilities turns into plans.

As most readers know, in June 2011 there will be two versions of the Platform released: 3.7 and 4.1. 3.7 is intended to be the most stable, production-proven version, which some adopters (many?) will need to use to "ship product" on, especially if they use non-API from the Platform, which may not be supported in 4.1. 4.1, though, is seen as the future of Eclipse, becoming the primary (only) version release stream in years to come. While it is anticipated to be production-ready by June 2011, it is not production ready as of this writing, so there is some risk to "putting all our eggs" in this one basket.

This puts us in a "transition" phase for the Simultaneous Release and this page is to list issues (and eventually plans) on how to accomplish this transition. Please feel free to add issues, questions (via your Planning Council representative).

Options

Completely split streams

One option is to simply have two completely different "streams", different repositories, different EPP packages, even different release "names". This simplifies some things, but a) should not be required (as far as is known) and b) is the most work for contributing projects (essentially doubling workload). It might also make a negative impression about the perceived compatibility of the two releases.

Only one stream

Of course, one option is just to pick one stream, and put all the focus there: either 3.7, implying 4.1 is still the "experimental" stream (which would not be good for 4.1), or 4.1, but which might lose support from many adopters that still need a solid release on 3.7. It it thought some form or "both streams in the release" is required.

One, compatible stream

Since 4.1 will have a compatibility layer ... so that code written to 3.x API will continue to run on 4.1 Platforms .... it is feasible that the Indigo release can consist of one set of bundles, that runs on both 3.7 and 4.1. This partially depends on a) how good the compatibility layer is, and b) how many non-api are used by contributing projects. This is likely the option that will take least amount of work from contributing projects, so will be the focus of the rest of these notes. The success of this option will depend on getting some quick answers on if it is feasible, or not, so will will be requesting that participating projects "report back" on their ability to participate not only in a "Simultaneous Release" but also a "Simultaneous Transition".

Assumptions

Binary compatibility between 3.7 and 4.1

Note that in this context, "4.1 Platform" means "4.1 Platform plus the compatibility layer" (if someone had a "pure" 4.1 application, they would not need the compatibility layer ... but we are assuming for now nearly everyone will need or use the compatibility layer).

It is assume that the two platform's are binary compatible, so that if code is compiled for 3.7, is can be ran on 4.1.

Recommended requirement: Code for delivery is compiled against 3.7 platform. Naturally, it is good practice to also compile against 4.1 so that the compiler can catch compile-time compatibility errors, but for consistency and easy of maintenance, we'd need consistency on compilation.

Implication: (or assumption?) Implicit in this and other assumptions is that no one makes use of new 4.1 specific platform features ... except the platform itself. Is this a safe assumption?

One common repository

It is assumed there can be just one Indigo repository that has both platform's, plus all the compatible bundles.

Compatible workspace

It would greatly assist user adoption, and committer testing and development, if they could use one workspace or at least their same of projects with each platform.

Plan A. One worksapce

It is assumed (required) that users can use 4.1 platform or the 3.7 platform and all their data, metadata, and preferences would be compatible between the two. This would be "round trip" for data or preferences that existed in both platforms. For new features/data that exist in only 4.1, then 3.7 based versions should ignore or gracefully handle things that it did not recognize. This scenario should be tested (to some degree) by all projects, and community, and bugs in this area given priority.

Plan B. One set of projects, two workspaces

If having literally one workspace is not technically feasible, then we should provide instructions for how to 'share projects' between workspaces using linked resources. This still implies project metadata is completely compatible with both Platforms, but the workspace-wide metadata itself would not need to be.

Plan C. Improve "sharing" functions

If neither of the above are possible, we might want to consider improving or providing some new "import/export" functions that would make it easier to move back and forth from one IDE to another, using the same projects or preferences.

EPP packages

This issue is complicated by use-cases needed by adopters, in addition to the "normal" one of what we provide to the general Eclipse user. Some adopters of course have their own, standalone products, which would not be effected by EPP packaging. But, sometimes, some adopters have a "product" that simply installs into existing installations of Eclipse, so they need some simple, fool proof way of telling their users what to install before installing their product. In addition, even those with "stand alone products", often support the scenario where users already have Eclipse or an EPP package installed, and then install the product into that existing version. We need to assess and test these various use cases.

Plan A: one package for both platforms

Ideally, it is desirable that both 3.7 and 4.1 Platform plugins could be present and the one used would be a function of a start-up parameter or "product" definition, so a particular EPP package could have 2 product definitions, and users could control which platform was used for their start up. (The default one would be chosen by EPP project or package maintainer).

Plan B: one package for one platform

Let's say the "package owner" (with input from community and committers) would decide which Platform to use in their EPP package.

Plan C: two package for each platform

This is one possibility, but would essentially double diskspace (and impact the mirroring system) and may add to some confusion about "which to download", instead of providing a simple "get going quick" web page.

Testing

Participating projects would be expected to test on both platforms (projects may emphasize one more than the other ... but expected to test on both to some extent).

No splitting steams for compatibly

Is is assumed (and would be required?) that no one splits streams to have a 3.7 based version and a 4.1 based version simply due to compatibility issues. For example, if it was discovered some coded used some non-API in the 3.x based versions, then the "fix" is not to have a new stream based on 4.1 using some other non-API ... but instead for participating projects to fix their code to use only API and/or the Platform to provide a new API that worked in both streams.

The case of splitting streams to make use of new API that is only in 4.1 is a slightly different case. In theory, that should be ok ... but, intuitively would seem to complicate things in a multiplicative fashion, not simply additive. This will have to be reassessed if we learn participating projects do have 4.1 specific function they want to take advantage of?

Time line

The dates chosen below are based on our regularly scheduled Planning Council meetings ... first Wednesday of the month.

1. September 1: have a draft-plan addressing this issue, from Planning Council, with PC member agreement on direction
2. October 6: update plan based on feedback from projects. Projects should state if they agree or disagree with direction. Hopefully some "empirical" validation that it will work. (For example, if a project found they used non-compatible internals (non-APIs) in thousands of lines of code, that might mean they could not commit to supporting a compatibility based transition plan.
3. November 3: update plan based on experience gained.
4. December 1: finalize plan, to be part of 2011 road map for Board Review.