Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?

[Matthias Sohn <matthias.sohn@xxxxxxxxx>]

On Wed, Jan 13, 2016 at 7:31 PM, Mickael Istria <mistria@xxxxxxxxxx> wrote:

On 01/08/2016 10:44 PM, 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.

What do you think about https://vid.me/K3GV ? Would you set fully-qualified versions with those 2 features?

this is awesome, when can I get this ?

So far I set strict version constraints manually and your new feature will make this a lot more efficient.

Maybe we could even go one step further and automate this in the following way:

At the beginning of each build of the simultaneous release repository the build job automatically applies

the following steps:

- find all included features for all participating projects which don't have a strict version constraint configured

- for these features automatically set a strict version constraint to the highest version of each feature available

  in the given p2 repository of the project

- commit these changes and push them to the branch this build is building

This would have the following effects:

- nothing changes for projects which already have set strict version constraints

- for projects which didn't set strict version constraints the build would change version constraints to the

  highest version available per feature.

- This may sometimes result in wrong content if multiple versions of a feature are available and

  the newest version is not the one which should be included. In order to signal such cases the

  build could build a log listing the features where this was the case (no strict version constraint

  configured and multiple versions of a feature available in the corresponding p2 repo).

  This list could be part of the commit message of the commit generated by the build so we have

  a versioned track record of what the build changed and what might be wrong with the generated change.

- finally this would guarantee that each build is based on a list of p2 repositories containing only

  features with strict version constraints

-Matthias

-Matthias