Skip to main content
Jump to: navigation, search

Difference between revisions of "Planning Council/January 06 2016/bug483322"

(Created page with "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 stabl...")
(No difference)

Revision as of 18:04, 6 January 2016

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:

Back to the top