Community
Participate
Working Groups
I imagine this is a function of "auto tagging", and I am not 100% how it used to look, and might be something I broke, but "branding bundles" I think are intended to change qualifiers each time they are built, but, I think it should be same as "buildId" not the literal time of the build or "time of the autotagging"? But, I might have "broken" something in trying to simplify things? One example, from M7 candidates: 128 < org.eclipse.jdt_3.8.0.v20120502-2016.jar (3.8 version) 129 --- 130 > org.eclipse.jdt_3.8.0.v20120503-1817.jar (4.2 version) I think those qualifiers should be v20120502-2000 and v20120503-1800 respectively.
FYI, seems all branding plugins are "off" in the same way ... as though its "branding qualifier" is being recomputed, instead of being passed the initial ${buildId} < org.eclipse.help.base_3.6.100.v20120502-2016.jar < org.eclipse.help.base.source_3.6.100.v20120502-2016.jar --- > org.eclipse.help.base_3.6.100.v20120503-1817.jar > org.eclipse.help.base.source_3.6.100.v20120503-1817.jar
Looking at 3.8 M6, all the branding plugins has a qualifier the same as the build ID, with v, but no 'I', and without the hyphen: org.eclipse.cvs_1.1.100.v201202280800.jar org.eclipse.cvs.source_1.1.100.v201202280800.jar org.eclipse.help.base_3.6.100.v201202280800.jar org.eclipse.help.base.source_3.6.100.v201202280800.jar org.eclipse.jdt_3.8.0.v201202280800.jar org.eclipse.jdt.source_3.8.0.v201202280800.jar org.eclipse.pde_3.6.100.v201202280800.jar org.eclipse.pde.source_3.6.100.v201202280800.jar org.eclipse.platform_3.8.0.v201202280800 org.eclipse.platform.source_3.8.0.v201202280800.jar org.eclipse.rcp_3.7.0.v201202280800.jar org.eclipse.rcp.source_3.7.0.v201202280800.jar org.eclipse.sdk_3.8.0.v201202280800 The ID in the about.mappings (for display on the about box) is the same as the build ID (with I, and with hyphen: I20120228-0800 In the current builds, the about.mappings/properties does have the correct build ID, for the about box: 0=I20120503-1800, and that's most important, I'd say. So ... not how much effort, if any, to put in to "fixing" the qualifiers ... I'm sure there is a way, but might get contorted with autotaggging? Not sure.
In bug 379493 comment 15, Paul pointed me at the piece of code that controls this: http://git.eclipse.org/c/platform/eclipse.platform.releng.eclipsebuilder.git/tree/eclipse/buildConfigs/sdk/customTargets.xml#n172 My guess is the "timestamp" used in that code used to be "passed along" from the same timestamp that was used to create the build id, but that got lost somewhere along the line, and now that timestamp, somewhere, is being "recomputed". I'll see if I can "back track", and "pass in" the "timestamp". If appears used for anything else, might change its name to "buildidtimestamp" to make it clearer what it is in this context. In theory, we could use the "buildId" minus the initial letter ... but ... that version would have a hypen in it, such as we'd end up with v20120516-1900 instead of v201205161900 (I personally think that would be a good thing ... I normally hate using hyphens to septate date and time but in this case think we should "match" style used in build Id ... so, be sure to say if there's some reason not to use they hyphen or if others have a preference).
Created attachment 215983 [details] patch to pass timestamp to the build I think this _is_ a simple matter of passing in the timestamp (we have already computed and created) from the "start" script to the ant script that does the build. From the logs, this value has what we want: 51 DEBUG: timestamp 201205182145 52 DEBUG: date: 20120518 53 DEBUG: time: 2145 Interesting to note I do (already) create a (temporary) variable named buildTimestamp ... with a hypen ... but all these variables should use some cleanup and "refactoring" to simplify. buildTimestamp=${date}-${time} buildTag=$buildType$buildTimestamp # TODO: it is confusing that buildId and buildLabel are the same # I think traditionally, buildId has been $date-$time and # buildLabel been $buildType$buildId # you can see this in some of the old build.property files: buildLabel=${buildType}.${buildId} # Note: this used to be set in the runSDKBuild function, but # are desired in some email messages, etc., before that runs. buildId=$buildType$date-$time buildLabel=$buildId The current "bad" value comes from a piece of code that (likewise) could use some consistency improvements: <target name="create.label.properties" unless="label.properties.exists"> <mkdir dir="${buildDirectory}" /> <tstamp/> <property name="date" value="${DSTAMP}" /> <property name="time" value="${TSTAMP}" /> <property name="timestamp" value="${date}-${time}" /> <property name="buildType" value="I" /> <property name="buildId" value="${buildType}${timestamp}" /> produces a label.properties file which is correct, except for the time stamp: 2 timestamp=20120518-2203 3 buildType=I 4 buildId=I20120518-2145 5 buildLabel=I20120518-2145 In "create label" task, the lines with "date" and "time" should likely be "buildDate" and "buildTime" that _are_ passed in. Then "timestamp" would e correct ... though, it would have a hypen. Thoughout the code there are hints of confusion (or, evolution?) of whether or not "timestamp" should have a hypen, but, I think the most recent stuff does not ... so, I think we could safely just pass in the timestamp we already have, get these version qualifiers to be consistent. The "cleanup" and code improvements could be done later. I'd like to fix this for RC2, unless other think it a non-issue.
Dani, marked you as reviewer, since you usually have an opinion (and good perspective) if you think the overall consistency with previous releases should be maintained ... or, if no big deal. In other words, just asking for you to review "importance" of making this fix now (not technical correctness).
(In reply to comment #5) > Dani, marked you as reviewer, since you usually have an opinion (and good > perspective) if you think the overall consistency with previous releases should > be maintained ... or, if no big deal. In other words, just asking for you to > review "importance" of making this fix now (not technical correctness). I think it's good to have the build ID in the branding bundle, because only due to the build ID we always build those bundles every time. And of course I always like consistency :-).
fix released for tonight's, 5/22 build. I've opened bug 380289 to track future "clean up and consistency" work.
verified in I20120522-1900 all these "branding bundles have the expected pattern. And ... not ill effects seen (so far :) org.eclipse.cvs_1.2.0.v201205221900.jar org.eclipse.cvs.source_1.2.0.v201205221900.jar org.eclipse.help.base_3.6.100.v201205221900.jar org.eclipse.help.base.source_3.6.100.v201205221900.jar org.eclipse.jdt_3.8.0.v201205221900.jar org.eclipse.jdt.source_3.8.0.v201205221900.jar org.eclipse.pde_3.7.0.v201205221900.jar org.eclipse.pde.source_3.7.0.v201205221900.jar org.eclipse.platform_4.2.0.v201205221900 org.eclipse.platform.source_4.2.0.v201205221900.jar org.eclipse.rcp_4.2.0.v201205221900.jar org.eclipse.rcp.source_4.2.0.v201205221900.jar org.eclipse.sdk_4.2.0.v201205221900
