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 flushing out these issues and will be updated as questions answered 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 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. This put 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.

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 we know) and b) is the most work for contributing projects (essentially doubling workload).

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

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

One common repository

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

One compatible workspace

It is assumed that user 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 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.

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.

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.

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.

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

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