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 
I am hoping Steffen and Benjamin might comment on any historical reason for the backward compatibility requirements.  I would tend to think that people using the Kepler version of MPC will be using it with Kepler.  However, I might be missing a use case?

Benjamin and Steffen any thoughts?

-----Original Message-----
From: mpc-dev-bounces@xxxxxxxxxxx [mailto:mpc-dev-bounces@xxxxxxxxxxx] On Behalf Of Carsten Reckord
Sent: May-07-13 11:24 AM
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