Planning Council/January 06 2016/bug483322
This is a discussion / proposal page for how we could implement a solution for bug 483322.
For Neon, if we wanted, we could easily produce only the most stable releases (Neon.0, Neon.1, Neon.2, Neon.3), releases with emergency/maintenance updates, and even a third option to include minor updates.
Here's how that could work, and what would be in the sites.
* This composite would only reference the main Neon(.x) site * No additional project-specific refs would appear here; we could even scrub them out of the content.xml if we wanted . * No out-of-band updates (ie., CDT couldn't push a 1.0.1.Final update into this site until Neon.1) * Projects would contribute x.y.0.Final bits only
* This composite would include the main Neon site + composite site refs to child projects' update sites (for emergency/maintenance updates only) * No additional project-specific refs would be exposed to Eclipse's Available Update Sites preference page, but p2 could still find & load those child sites * Out-of-band updates possible here (ie., CDT could push a 1.0.1.Final update into this site one day after Neon.0, without having to wait months for Neon.1) * Projects would contribute x.y.0.Final bits, plus any x.y.z.Final bits too * No x.(y+1).0 or (x+1).0.0 updates permitted, as those are minor/major updates and could break API/introduce new/unexpected features
* This composite would include the main Neon site + composite site refs to child projects' update sites (for minor & maintenance updates) * No additional project-specific refs would be exposed to Eclipse's Available Update Sites preference page, but p2 could still find & load those child sites * Out-of-band updates possible here (ie., Mylyn could push a 3.18.0 update to its 3.17.0 bits in Neon.0 a day after Neon.0 ships, without having to wait months for Neon.1) * Projects would contribute x.y.0.Final bits, plus any x.y.z.Final or x.(y+1).0.Final bits too * x.(y+1).0 updates are permitted, at the projects' discretion, as long as no features are REMOVED or unexpected UI changes occur without reasonable cause (eg., fixing a UX problem?) * No (x+1).0.0 updates permitted, as those are major updates and could break API.
Here's a sample of what these composite*.xml files could look like:
Steps to implement
Implementation requires small changes by each project that contributes to the simrel process.
These changes effectively separate artifact publishing from artifact update policy.
1. All the projects would be required to remove any feature.xml, p2.inf, or other instructions/metadata that hard-code an update site URL into their update site or their contributions to the Neon site. This would allow site #1 above to be pure, with no external update site references to projects' update sites.
2. All the projects would be encouraged to submit a pull request to http://download.eclipse.org/releases/neon/maintenance/composite*.xml (and to http://download.eclipse.org/releases/neon/minor/composite*.xml too if they choose) to contribute their update site URL to the overall composite site.
3. EPP packages should be updated to include by default these URLs:
* http://download.eclipse.org/releases/neon/maintenance/ (enabled by default; includes http://download.eclipse.org/releases/neon/ inside its list of children sites) * http://download.eclipse.org/releases/neon/minor/ (disabled by default; includes http://download.eclipse.org/releases/neon/maintenance inside its list of children sites)
Benefits / Impacts
1 This would allow BY DEFAULT that all EPP package users could discover project updates from /maintenance/, and to be able to optionally enable /minor/ updates too, if they want those arguably less stable too.
2. By creating these new composite sites in new URLs under /maintenance/ and /minor/, nothing has to change in the root /releases/neon/ site in terms of how it's built & published.
3. By creating a place for maintenance updates, we can let projects provide bugfixes at a faster cadence than the quarterly simrel releases, balancing stability with continuous integration.
4. By creating a place for minor updates, we can let projects move at a faster cadence than the quarterly simrel releases, for those users who want more frequent change (eg., early adopters, companies working closely with / contributing to upstream Eclipse projects for their own products).
 - JBoss Tools uses a maven mojo that scrubs external refs when creating an update site. You can also use an Ant script with XSLT:
As an alternative naming scheme to folder names /maintenance/ and /minor/, we could go with /stable/ and /development/.