Would it make sense for the b3 editor to semi-automatically fill in / update the versions of the plug-ins from the p2 site specified?
The user flow would then be: 1) Publish p2 site with new content 2) Update b3 file with p2 site URL 3) Invoke action to update versions based on p2 URL 4) Commit & Push Jonah ~~~ Jonah Graham Kichwa Coders Ltd. www.kichwacoders.com On 8 January 2016 at 16:15, Eike Stepper <[email protected]> wrote: > Hi, > > I may misunderstand this fixed version stuff, so I better ask explicitely. > I will not be forced to author exact feature versions in my contribution > files, right? > > I'm fine with the rule of contributing only fixed content, but I prefer to > achieve that goal with non-changing repos. > > Cheers > /Eike > > ---- > http://www.esc-net.de > http://thegordian.blogspot.com > http://twitter.com/eikestepper > > > > Am 08.01.2016 um 17:09 schrieb Mickael Istria: > >> On 01/07/2016 07:40 PM, David M Williams wrote: >> >>> [email protected] wrote on 01/07/2016 >>> 12:30:21 PM: >>> >>> > From: Mickael Istria <[email protected]> >>> > To:[email protected], >>> > Date: 01/07/2016 12:30 PM >>> > Subject: Re: [cross-project-issues-dev] Enforce Gerrit for Simrel? >>> > Sent by:[email protected] >>> > >>> > ... >>> > Good. I wasn't aware of that. That's a major step forward. >>> > However a quick lookup on b3aggrcon files shows that many (probably >>> > the majority) of contributions seems to ignore that rule; as they >>> > either don't specify a versionRange or specify a versionRange in a >>> > [a.b.c,x.y.z] way. >>> > >>> >>> Yep. You have stated your desire to "test for that" ... so have at it. >>> (But, do read the "rule" carefully ... it is an either/or type. One >>> condition is easy to test for with simply the text input. The other would >>> have to look at the source repository and make sure it was a 'simple' >>> repository (not a composite). >>> >> Would a contribution that adds/sets the fully qualified version to all >> current b3aggrcon files missing it be welcome? Projects contributing >> volatile content fail the build next time they update their contributed >> repo, so we'll know which projects need to be educated to this new rule >> (there's already one contributed by me that's now an outlaw ;) ). >> Once we have a good basis, I'll make an addition validation job that >> checks that this rule on all incoming Gerrit contributions. >> -- >> Mickael Istria >> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> >> My blog <http://mickaelistria.wordpress.com> - My Tweets < >> http://twitter.com/mickaelistria> >> >> >> _______________________________________________ >> 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 >> > > > _______________________________________________ > 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 >
_______________________________________________ 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
