Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
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 have a mix of both "only the most stable" releases (Neon.0, Neon.1, Neon.2, Neon.3), releases with emergency/maintenance updates, and even a third option for *minor* updates.
Sites
1. http://download.eclipse.org/releases/neon/
* 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 [1]. * 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
2. http://download.eclipse.org/releases/neon/maintenance/
* 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
3. http://download.eclipse.org/releases/neon/minor/
* 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.
Steps to implement
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. *This effectively separates artifact publishing from artifact update policy.*
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)
4. 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.
5. 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.
6. 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.
7. 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).
--
[1] - JBoss Tools uses a maven mojo that scrubs external refs when creating an update site. You can also use an Ant script with XSLT: