Bug 483321

Description Konstantin Komissarchik 2015-11-30 12:33:22 EST

Currently, many projects auto-register an updates repository using the referenced repositories feature or p2 hooks. This a work-around for the fact that simultaneous release process currently does not provide a way to deliver fixes between the coordinated releases. This approach has unintended consequence of baking in an update policy into the project's release artifacts. This makes it difficult for third-parties to create distributions with a different update policy and is one of the things that is standing in the way of Eclipse having multiple integration streams, as practiced elsewhere.

This is a proposal to make a small change to the current simultaneous release process to provide a mechanism for projects that are part of the simultaneous release to deliver updates. Implementing this proposal will remove the need for the current work-around.

1. Start with the current simultaneous release process

2. Add a reference repository URL to the simultaneous release repository, such as http://download.eclipse.org/releases/mars/updates

3. The updates repository will be a composite to which projects can contribute references to releases that happen in between coordinated releases

4. The updates composite is managed by the "updates administrator" (I will volunteer or Planning Council can appoint someone else)

5. The burden is on the project to test compatibility. If a project contributes an update in this manner and a cross-project issue crops up, once the issue is validated, the updates administrator immediately drops the project's repository from the updates composite, thus returning us to a known good state. Then it's up to the project to rectify the issue with a new release before being re-added. In some cases, it might mean that the project has to wait for another project to update first or work with them at our coordinated release points.

There is no new risk in this approach. Currently, if the user doesn't wish to receive out-of-band updates, they need to disable all the repositories added by various projects. Similarly, after this proposal is implemented, the user would need to disable the simrel updates repository for the same effect.

Implementing this proposal will gain us additional tools in dealing with cross-project issues (seen #5) and would decouple project release artifacts from the update policy.