Hi
My 'contribution' is currently:
<repositories
location="http://download.eclipse.org/modeling/mdt/ocl/updates/milestones/6.1.0/S201512161807"
description="Eclipse OCL 6.1.0">
<features name="org.eclipse.ocl.all.sdk.feature.group"
versionRange="[5.1.100,5.3.0)">
<categories
href=""/>
<categories
href=""/>
</features>
<features name="org.eclipse.ocl.examples.feature.group"
versionRange="[6.0.100,6.2.0)">
<categories
href=""/>
</features>
</repositories>
"6.1.0/S201512161807" is a build-specific repo. If that is
auto-updated great. However if it is auto-updated I lose the ability
to delay the update, possibly because I want to do some more
testing. More likely because the aggregator is having trouble or
Hudson is down.
IMHO given build-specific repos, the version range is redundant
clutter and arguably the source of much of this trouble.
Regards
Ed Willink
On 08/01/2016 21:44, Mickael Istria
wrote:
On 01/08/2016 07:13 PM, Eike Stepper
wrote:
Am
08.01.2016 um 17:29 schrieb Marc Khouzam:
I also would not like to have to change
versions.
Changing the URL only allows me to change one line quickly.
Changing each version of each feature group is more work and
more error prone.
Exactly. I also don't want to look *into* my repos for each
contribution and copy multiple versions around.
Just to be sure I correctly understand your (and Marc's and Ed's)
point: you're OK to have fully-qualified versions in the file, but
you don't want to maintain it manually, right?
So if the b3 model editor were providing that, would it suit you?
Would you specify fully-qualified versions to the aggregator? If
it's the only thing blocking you and others in using
fully-qualified versions, I may be able to raise the priority of
this improvement in my todo-list.
_______________________________________________
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
|
