Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] Version ranges in bundle dependencies

I think that this should also be brought up at the Papyrus IC architecture committee to align all Papyrus products along the same line (Papyrus IC steering committee copied).

/Charles

On 2016.06.14, at 07:53 , Christian Damus <give.a.damus@xxxxxxxxx> wrote:

Hi, Philip,

I would advocate adoption of the policy that you suggest.  The Papyrus project has implemented a similar policy.  The Papyrus Developer Tools also provide some handy actions for automating management of bundle dependencies, re-exports, and version ranges, as described in that wiki page.

Cheers,

Christian

On 14 June, 2016 at 06:33:39, Philip Langer (planger@xxxxxxxxxxxxxxxxx) wrote:

Hi,

is there a policy on specifying the version ranges in bundle dependencies for Papyrus-RT?

While double-checking the dependencies on plug-ins I intend to add to Papyrus-RT, I checked a few existing plug-ins and it seems that the version ranges are not always specified consistently across all plug-ins. For instance, in core/ the min versions are specified, except for eclipse.core.runtime or eclipse.ui, which has no version range. Max version is never specified. In common/, however, we have min and max versions for eclipse.ui and eclipse.core.runtime, and only min for internal dependencies.

So I thought I put this topic up for discussion, whether such a policy should be introduced.

In other projects, such as EMF Forms, we always set min and max versions for all (eclipse platform, external projects, and internal plug-ins) as follows:
  * min inclusive of the earliest version we intend to support; typically, this is at least the current version at the time of adding the dependency
  * max exclusive of the next major, if only public API is used from the dependency
  * max exclusive of the next minor, if also "SPI" / "internal API" is used

Thus, the typical dependency would look like this, if only public API is used:
org.eclipse.papyrus.infra.core.log;bundle-version="[1.2.0,2.0.0)"

While this certainly demands some additional effort in setting it up and maintaining it, it enables quite high level of security to detect API issues early and avoid version conflicts.

What do you think?

Thanks and best wishes,

Philip

--
Philip Langer

Senior Software Architect / General Manager
EclipseSource Services GmbH
_______________________________________________ 
papyrus-rt-dev mailing list 
papyrus-rt-dev@xxxxxxxxxxx 
To change your delivery options, retrieve your password, or unsubscribe from this list, visit 
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev 
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


Back to the top