[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Fwd: Change 73676 insimrel/org.eclipse.simrel.build[master]: Update PTP to RC2

Hi Michael

My (mis-)understanding of David's fix:

- <features name="org.eclipse.mylyn.github.feature.feature.group" versionRange="[4.4.0.201605250940-rc1]">
+ <features name="org.eclipse.mylyn.github.feature.feature.group" versionRange="[4.4.0.201605252217]">

was that he replaced one ephemeral 4-part reference by another. Hence my observations that we could reduce problems by avoiding ephemeral provision and 4-part consumption.

I fully agree that providers should be fully qualified helping to avoid ephemeral P2 replacements and to ensure that we know what was contributed.

The problem here is that a consumer is over-specified (unless of course EGIT really is tightly coupled to an RC1/RC2 Mylyn change.)

    Regards

        Ed Willink

On 26/05/2016 10:03, Mickael Istria wrote:
On 05/26/2016 10:53 AM, Ed Willink wrote:
We have perhaps 30 projects that depend on EMF.
If
- each project specifies a precise 4-part EMF version dependency
Project should simply not do that, and as far as I know, they don't.
- EMF deletes all old versions before creating a new contribution
Then every time EMF re-contributes, the aggregator will fail until all 30 projects have caught up. In the meantime another popular dependency such as GEF may cause further grief.
The constraint of enforcing a build-specific site and/or fully-qualified versions in SimRel contribution files doesn't imply that contributing project have to rebuild nor change anything.
Projects are free to define references to their dependencies as best for them at build-time. It's only in SimRel that fully-qualified versions are recommended for easier tracking of what gets included, not in individual projects.
Basically, I don't understand how this story and the initial Simrel issue are related.

--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev