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: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
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 <cross-project-issues-dev@xxxxxxxxxxx>,
Date: 01/17/2013 12:14 PM
Subject: Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
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 <cross-project-issues-dev@xxxxxxxxxxx>,
Date: 01/17/2013 10:37 AM
Subject: Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
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 <cross-project-issues-dev@xxxxxxxxxxx>,
Date: 01/17/2013 11:19 AM
Subject: Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
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 (cross-project-issues-dev@xxxxxxxxxxx)" <cross-project-issues-dev@xxxxxxxxxxx>,
Date: 01/17/2013 08:39 AM
Subject: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
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
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
