Hi all, The reason why I (and others, eg CDT) started using "loose version specifiers" and composite repos was, That we wanted to avoid the manual task of editing our versions in the B3 editor with every contribution.
I was not aware of the recommendation to use explicit versions so far. So if that is the recommendation, the next question is : Does anybody have any automated way of promoting builds with explicit version specifiers to the simrel ? What is the Planning Council's recommendation how to update the .b3aggr files ? Thanks, Martin -- Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: [email protected] [mailto:[email protected]] On Behalf Of David M Williams Sent: Thursday, January 17, 2013 7:43 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository What versions were you trying to contribute? I notice your Juno_maintenance version and master version point to different repositories, but each specify the same version of features ... there's nothing wrong with that! ... but, just wondering if that's what you intended? Just going by the file system, I see you specified org.eclipse.rse versionRange="3.4.0" and what's on the ../releases/maintenance file system is org.eclipse.rse_3.4.1.201209191030-7L7IFBY83omx__z0RFpKdWB-r5MS but you have a more recent version in ..../3.4milestones/SR2_RC1a/features/org.eclipse.rse_3.4.1.201301071106.jar There is a couple of ways the aggregator (actually p2) could get the "wrong" version. It is basically just looking for a solution "that satisfies all the constrains". And yes it will try to 'get the highest version' but a) not sure that's guaranteed 100% and (more likely) someone else could say "I want exactly version of XYZ" in which case p2 might well be able to satisfy their requirement, with your "loose" requirement of one repository, that has lots of versions in it, and the only thing you specify is 'higher than 3.4.0'. All of that leads me to my point ... I always recommend people specify _exactly_ what they want in the versionRange attribute, such as one example I saw as versionRange="1.6.0.v20120328-0001-67T-95GFz05DNIrNLOSNK_NPj507" OR, often easier, to me, is to specify a very specific repo that has only one version of that you want to contribute, such as for you ... .../tm/updates/3.4milestones/SR2_RC1a (If that was the one you wanted). Occasionally this might lead to "early warnings", such as the aggregator (p2) will complain "so and so wants exactly version XYZ but was not found" and then everyone knows ... but, without specific constraints, p2 is doing its job of finding "a solution". For builds, you normally want to be sure they are exact, and repeatable. Oh, and there are probably many less interesting things that could be going wrong :) ... but, that's the basics. HTH From: David Dykstal/Rochester/IBM@IBMUS To: Cross project issues <[email protected]<mailto:[email protected]>>, Date: 01/17/2013 12:14 PM Subject: Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository Sent by: [email protected]<mailto:[email protected]> ________________________________ I agree. Warmups are good. I really did mean /tm/updates/3.4milestones. I could have created one specifically for SR2, but we have been storing our milestone builds for our service releases in the directory I used. Seemed like the right spot for the repo. The aggregation editor does show the features existing under "available versions" and I am on the Juno_maintenance branch. Is there some sort of filtering going on that is missing that version? -- David Dykstal, Architect - Rational Developer for Power Systems From: David M Williams/Raleigh/IBM@IBMUS To: Cross project issues <[email protected]<mailto:[email protected]>>, Date: 01/17/2013 10:37 AM Subject: Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository Sent by: [email protected]<mailto:[email protected]> ________________________________ Well, that's why we do a warmup :) Did you meant to contribute .../tm/updates/3.4 to Juno or ... /tm/updates/3.4milestones? I see the former in 'master' and later in 'Juno_maintenance'. I can't tell by the names, but often XXMilestones implies something older than XX repository? You need to use the Juno_maintenance branch of org.eclipse.simrel.builds project. HTH From: David Dykstal/Rochester/IBM@IBMUS To: Cross project issues <[email protected]<mailto:[email protected]>>, Date: 01/17/2013 11:19 AM Subject: Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository Sent by: [email protected]<mailto:[email protected]> ________________________________ It looks like my first attempt at contributing to the aggregation build failed. If I'm reading the reports correctly I see the TM SR1 plugins there rather than the ones from the repository I thought I had contributed. Obviously my understanding of how the contribution files work is incorrect. Can someone give me a hand here and look at tm.b3aggrcon? -- David Dykstal, Architect - Rational Developer for Power Systems From: David M Williams/Raleigh/IBM@IBMUS To: "Cross project issues ([email protected]<mailto:[email protected]>)" <[email protected]<mailto:[email protected]>>, Date: 01/17/2013 08:39 AM Subject: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository Sent by: [email protected]<mailto:[email protected]> ________________________________ Sorry, fell asleep last night :) when I should have been sending out this notice. But, we are done with SR2 RC1 warm-up repo. Remember its "staging" location is http://download.eclipse.org/releases/maintenance/ Besides testing that repo, be sure to check the repository reports ... looks like a few regressions for required files, signed jars, etc. http://build.eclipse.org/simrel/juno/reporeports/ In addition to testing only that single repo, be sure to test it as a "composite", since eventually it will be added to .../releases/juno as a child repository. See http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#Test_staging_as_a_pseudo_composite Don't forget to test "update" scenarios (some of which need to wait for EPP repositories to be ready, if they are not already). Recall that there is no "promotion" of this repo. It will simply be "left alone" for about a week ... until Juno SR2 RC2 +0. http://wiki.eclipse.org/Juno/Simultaneous_Release_Plan#SR2 As a "warm-up", we don't expect this to be a true "release candidate", but please approach RC2, RC3, etc., with the attitude that those will be true "release candidates" suitable for adopter acceptance testing, etc. Thanks, _______________________________________________ cross-project-issues-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
