On Wed, Jan 13, 2016 at 7:31 PM, Mickael Istria <[email protected]> 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
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
