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