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 would think the we need to move to a 0.8 release stream as soon as possible (do be determined by the architects).

It is extremely unlikely that we would release any further 0.7 releases.

/Charles


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

Yes, if you set the lower bounds of all dependencies to 0.8 but don’t update the versions of those dependency bundles to 0.8 or greater, then none of the Papyrus-RT bundles will be resolved at run-time because their dependencies will be unsatisfied.

cW



On 14 June, 2016 at 09:52:32, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:

+1 to having a policy.

I assume that the min version for everything in master right now should be 0.8?

A technical question: in order to set the min version for dependencies which are Papyrus-RT plugins to 0.8 (or whatever is decided) we would need to update all plugins' version numbers, right?



On Tue, Jun 14, 2016 at 8:49 AM charles+zeligsoft.com <charles@xxxxxxxxxxxxx> wrote:
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

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