For record, I think this will cause problems if not used in conjunction with a mechanism that generate increasing version numbers for the bundles.
The reason why we initially came up with the algorithm that generated long qualifiers for feature is because we wanted to be resilient to additions, removals,
version changes, etc. For example, what happens if the bundle with the highest version is now removed from the feature, or what if one of the dependency that gets pulled in from a repo has changed, etc…
One case that I’m really worried about is one where one of the bundles gets the version that is the same than the one with the highest version. To be concrete
Feature F has
Bundle A v2013
Bundle B v2012
In this case Feature F version is v2013.
Now Bundle B needs to be rebuilt and gets the version v2013, the feature version will still be v2013 and the expected change will not be delivered.
This may sound theoretical but in the reality will happen when we iterate very quickly over RC builds.
From: platform-releng-dev-bounces@xxxxxxxxxxx [mailto:platform-releng-dev-bounces@xxxxxxxxxxx]
On Behalf Of David M Williams
Sent: February-15-13 2:25 AM
To: Eclipse platform release engineering list.
Subject: Re: [platform-releng-dev] CBI based 4.3.0 I-Build: I20130214-2011 <== Finally!
Yes, it is expected. The algorithm they came up with was (recalling from memory) the feature gets the same qualifier as the highest qualifier for what it contains. In our case,
that means many will change every build since our branding bundles changes qualifier every build. But ... overall a good tradeoff. Even without branding bundles, I think there's some "theoretical" cases where you can "revert" some code, so the qualifier (and
feature) ... now, with new heuristics, ... then increment, even though its exactly equal to what a user might already have installed ... but, again, a fair tradeoff for all of our use-cases. (But, a good example of something to "keep an eye on" and make sure
it works as expected over time, with various nested features, etc.).
From: Ian Bull <irbull@xxxxxxxxxxxxxxxxx>
To: "Eclipse platform release engineering list." <platform-releng-dev@xxxxxxxxxxx>,
Date: 02/15/2013 01:33 AM
Subject: Re: [platform-releng-dev] CBI based 4.3.0 I-Build: I20130214-2011 <== Finally!
Sent by: platform-releng-dev-bounces@xxxxxxxxxxx
I gave this a really quick spin, and generally things look like they are in place. In particular I was looking through the install software dialog to make sure that the p2 metadata looked ok. I even tried to install some stuff (CDT) into the install and that
worked well. Great job!
One thing I did notice was that our feature versions are a lot nicer now (no long complicated hash anymore). I remember this was discussed last year and there were a few concerns about how to properly compute the version. I don't remember the details, but I
just wanted to check that this new (shorter) versions is expected.
Cheers,
Ian
On Thu, Feb 14, 2013 at 10:00 PM, David M Williams <david_williams@xxxxxxxxxx> wrote:
Oh, one other thing to make sure everyone knows ... I changed the Hudson settings for these unit tests to "run concurrently" because serially will drag things out. On Linux, this should work fairly well ... but
I was hoping that would mean it would "pick a different machine" to run the second one on, but that doesn't seem to be the case tonight (the first time we've done it). So, if any one has errors that are hard to explain, that might be one reason. (For example,
if your tests read and write files of same name to /tmp folder, there'd be opportunity for them to step on each other.
From: David M Williams/Raleigh/IBM@IBMUS
To: "Eclipse platform release engineering list." <platform-releng-dev@xxxxxxxxxxx>,
Date: 02/15/2013 12:49 AM
Subject: Re: [platform-releng-dev] CBI based 4.3.0 I-Build: I20130214-2011 <== Finally!
Sent by: platform-releng-dev-bounces@xxxxxxxxxxx
Happy valentine's day, committers. This build appears good for evaluation and use. Please download, install, and use as dev. env. Make sure nothing's obviously missing, extra or wrong. But, remember, care is needed if tempted to updating from a site repository
... first, because we don't have one yet for our CBI based builds! And second, there are some versioning differences still so there _might_ be a day where some "go down" in lexicographical order. One thing to watch for is if you make a commit in the next few
days is to check that subsequent build, and make sure your qualifier changed as expected.
Do note, however, the qualifiers will now be based on UTC, rather then Eastern Time, so depending on where you live, you may need to do the math to see if it "matches the time" you made the commit.
Thanks,
From: "e4Builder" <e4Build@xxxxxxxxxxx>
To: platform-releng-dev@xxxxxxxxxxx,
Date: 02/14/2013 10:52 PM
Subject: [platform-releng-dev] CBI based 4.3.0 I-Build: I20130214-2011
Sent by: platform-releng-dev-bounces@xxxxxxxxxxx
Download:
http://download.eclipse.org/eclipse/downloads/drops4cbibased/I20130214-2011/
_______________________________________________
platform-releng-dev mailing list
platform-releng-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-releng-dev
_______________________________________________
platform-releng-dev mailing list
platform-releng-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-releng-dev
_______________________________________________
platform-releng-dev mailing list
platform-releng-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-releng-dev
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com |
http://twitter.com/eclipsesource _______________________________________________
platform-releng-dev mailing list
platform-releng-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-releng-dev
