Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mpc-dev] Remediation support and MPC target platforms


as far as I remember we kept MPC backwards compatible since it was a reasonable effort and it enabled users on Helios to consume new features in MPC. I don't know to what extend users or integrators actually install newer MPC releases on older Eclipse versions though. It wasn't a requirement that was requested by the community but something that we wanted to provide to target a larger audience.

Backwards compatibility is always a trade off between consuming newer platform features, effort required and target audience. If there is a significant benefit in moving to Kepler and high effort to continue maintaining backwards compatibility I would drop support for releases before Kepler. As Martin pointed out integrators can always consume older MPC releases or backport the current release to their targeted Eclipse stream (and contribute that back).

Reducing the number of Eclipse targets also reduces testing overhead and if we have a very good reason (which sounds like it) it seems fine to do this late in the cycle.


On Tue, May 7, 2013 at 5:30 PM, Oberhuber, Martin <Martin.Oberhuber@xxxxxxxxxxxxx> wrote:
Hi Carsten,

I'd assume that 99% of the people who use an old release, would also use the old MPC with that release.

So the real question is : Given the great and very relevant improvements that you've made in Kepler so far, how important is it for you to make these available on the old releases ?

One possible approach would be simply freezing the Kepler MPC as of today - calling it MPC 1.2 and continuing maintenance bugfixes on it for the old releases.
Then for Kepler, adopt Pascal's changes and call it MPC 1.3 moving forward, supporting only Kepler and later.
That approach would only make sense when additional features and fixes (post Kepler) are not meant to be backported typically.

Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

-----Original Message-----
From: mpc-dev-bounces@xxxxxxxxxxx [mailto:mpc-dev-bounces@xxxxxxxxxxx] On Behalf Of Carsten Reckord
Sent: Tuesday, May 07, 2013 5:24 PM
To: Communication between MPC committers
Subject: [mpc-dev] Remediation support and MPC target platforms

Hi all,

P2 has introduced the concept of remediation in its M7 release, assisting users with resolution strategies when dependency resolution fails.

Pascal Rapicault was so nice to submit a patch to enable remediation in MPC:

The patch is looking very good and we'll be able to add working remediation support for our M7 release, with Pascal working on an even more streamlined remediation workflow for RC1 or earlier.

This has brought up the question of supported target platforms however:

We currently target all Eclipse releases starting with Helios with a single MPC release. For new API that we want to use - like the remediation API - this usually means using reflection to check for its presence and to avoid runtime dependencies. On the plus side, it also means avoiding maintenance branches and backporting bugfixes or new features.

I'd like to ask opinions on this practice. Do you think we should

a) keep targeting all Eclipse releases with a single MPC codebase, adding complexity for using new API, but simplifying maintenance otherwise?
b) target only the current Eclipse release with new MPC releases, only backporting important bugfixes to maintenance versions? This would simplify including new features, but increase maintenance overhead for older platforms.

Given the current commit activity, both would be doable.

Personally, I think with the project plan supposedly fixed since M6, specifying >= 3.6 compatibility, and the final release just a couple of weeks ahead, it's a bit late to change this now.

Also, it comes down to just how many users are out there using MPC with old releases - I have no idea, but in my experience there's still a fair amount of Indigo and Helios users out there...


Carsten Reckord
  t  +49 561 5743277-33
  f  +49 561 5743277-8833
  e  reckord@xxxxxxxx

Yatta Solutions GmbH
  Sitz der Gesellschaft: Kassel
  Amtsgericht Kassel, HRB 14720
  USt-IdNr DE263191529

  Johannes Jacop,
  Dr. Christian Schneider

  Ludwig-Erhard-Straße 12
  34131 Kassel

  t  +49 561 5743277-0
  f  +49 561 5743277-88
  e  info@xxxxxxxx

  Kasseler Bank eG
  BLZ 520 900 00
  Kto-Nr 158 305

mpc-dev mailing list
mpc-dev mailing list

Steffen Pingel
Principal Software Engineer, Eclipse Mylyn
Mylyn Tasks Lead

Back to the top