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 
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.

Thanks,
Martin
--
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:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=406907

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...


Best,
Carsten

--
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

Geschäftsführung:
  Johannes Jacop,
  Dr. Christian Schneider

Adresse:
  Ludwig-Erhard-Straße 12
  34131 Kassel

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

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

_______________________________________________
mpc-dev mailing list
mpc-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mpc-dev

Back to the top