Re: [orbit-dev] R build for Galileo SR2

[DJ Houghton <DJ_Houghton@xxxxxxxxxx>]

I checked the changes to my bundles and the only difference for org.apache.ws.commons.util is:
   https://bugs.eclipse.org/bugs/show_bug.cgi?id=292214 - Missing bundle provider in manifest
So no code change and I would say it isn't required for a maintenance build.

I would vote to:
- branch org.eclipse.orbit.releng, rooted from our last R build (call it Galileo_maintenance maybe?)
- modify the map file with changes to only those bundles which are necessary
- build the R-build from the new branch

dj


David M Williams ---01/06/2010 06:04:32 PM---> ... What are the plans to get an R build? > At this point I'm satisfied with the content of ...

From:	David M Williams <david_williams@xxxxxxxxxx>
To:	Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
Date:	01/06/2010 06:04 PM
Subject:	Re: [orbit-dev] R build for Galileo SR2
Sent by:	orbit-dev-bounces@xxxxxxxxxxx

---

> ... What are the plans to get an R build?
> At this point I'm satisfied with the content of ... 

Darn. I was hoping we would not need a new R build. :) 

And ... I assume ... you are saying you do need a new one? 
For Galileo maintenance? 
Probably to get both of the new sat4j bundles? 

org.sat4j.core_2.1.1.v20090825.jar 
org.sat4j.pb_2.1.1.v20090825.jar 

instead of the old 

org.sat4j.core_2.1.1.v20090812.jar 
org.sat4j.pb_2.1.1.v20090812.jar 

Those 13 days made a big difference, eh? :) 

I think this time, we probably should not simply take our latest Helios S build, for our Galileo R build. 
There's been lots of changes ... some maybe needed? But some might "surprise" some adopting projects? 

Below is my detailed analysis, just based on "surface", I did not look at bugzilla to see what was 
fixed. In the next few days, if we hear a loud outcry that all the changes are also needed in maintenance, 
maybe we'll reconsider, but otherwise, we will be safer to start a maintenance branch of map files, and 
require explicit action for someone to get a change into maintenance. 

= = = = = = 

>From taking a 'diff' of latest R build and latest S build (not looking 
at how/if files differed, but only which jars are 'new' or 'absent' ... 
BUT, which were _similar_ to existing ones. 

Old, Only in orbit-R20090825191606 

Only in orbit-R20090825191606/eclipse/plugins: javax.servlet_2.5.0.v200806031605.jar 
Only in orbit-R20090825191606/eclipse/plugins: org.apache.derby_10.1.2.1_v200803061811.jar 
Only in orbit-R20090825191606/eclipse/plugins: org.apache.ws.commons.util_1.0.0.v20081204.jar 
Only in orbit-R20090825191606/eclipse/plugins: org.apache.ws.commons.util_1.0.1.v20081204-1018.jar 
Only in orbit-R20090825191606/eclipse/plugins: org.sat4j.core_2.1.1.v20090812.jar 
Only in orbit-R20090825191606/eclipse/plugins: org.sat4j.pb_2.1.1.v20090812.jar 
Only in orbit-R20090825191606/eclipse/plugins: org.slf4j.api_1.5.6.v200903200722.jar 

New, Only in orbit-S20091203150826 

Only in orbit-S20091203150826/eclipse/plugins: javax.servlet_2.5.0.v200910301333.jar 
Only in orbit-S20091203150826/eclipse/plugins: org.apache.derby_10.5.1.1_200912031533.jar 
Only in orbit-S20091203150826/eclipse/plugins: org.apache.ws.commons.util_1.0.0.v20091022-1630.jar 
Only in orbit-S20091203150826/eclipse/plugins: org.apache.ws.commons.util_1.0.1.v20091022-1635.jar 
Only in orbit-S20091203150826/eclipse/plugins: org.sat4j.core_2.1.1.v20090825.jar 
Only in orbit-S20091203150826/eclipse/plugins: org.sat4j.pb_2.1.1.v20090825.jar 
Only in orbit-S20091203150826/eclipse/plugins: org.slf4j.api_1.5.6.v20090930-0800.jar 

How many of those 7 new ones are _required_ for maintenance? 

Completely new bundles, in Orbit S build. Could any cause "confusion" with similar/matching bundles 
(that previously were contributed to Galileo from individual Projects, not Orbit). 

Only in orbit-S20091203150826/eclipse/plugins: com.google.gwt.servlet_1.7.0.v20091020-1225.jar 
Only in orbit-S20091203150826/eclipse/plugins: com.google.gwt.user_1.7.0.v20091019-0813.jar 
Only in orbit-S20091203150826/eclipse/plugins: javax.inject_1.0.0.v20091030.jar 
Only in orbit-S20091203150826/eclipse/plugins: net.miginfocom.layout.swing_3.7.1.v200911230030.jar 
Only in orbit-S20091203150826/eclipse/plugins: net.miginfocom.layout.swt_3.7.1.v200911230030.jar 
Only in orbit-S20091203150826/eclipse/plugins: net.miginfocom.layout_3.7.1.v200911230030.jar 
Only in orbit-S20091203150826/eclipse/plugins: org.kohsuke.args4j_2.0.12.v200910131500.jar 
Only in orbit-S20091203150826/eclipse/plugins: org.objectweb.asm_3.2.0.v200909071300.jar 

Only in orbit-S20091203150826/eclipse/plugins: org.apache.commons.jxpath_1.3.0.v200911051830.jar 
Only in orbit-S20091203150826/eclipse/plugins: org.apache.log4j_1.2.15.v200910021404.jar 
Only in orbit-S20091203150826/eclipse/plugins: org.junit_4.7.0.v20091118-1515 
Only in orbit-S20091203150826/eclipse/plugins: org.mozilla._javascript__1.7.2.v200909291707.jar 



Yes. While 8 of these 12 are completely new and distinct, hence safe, 
from looking at ~/downloads/releases/helios, there are 4 similar, previously 
existing Galileo versions ... that _might_ cause "confusion" with the more recent versions. 

org.apache.commons.jxpath_1.2.0.v20080604-1500.jar 
org.apache.log4j_1.2.13.v200903072027.jar 
org.junit_3.8.2.v20090203-1005.jar 
org.mozilla.rhino_1.7.1.v20090521.jar (same _packages_ as the new org.mozilla._javascript_ bundle) 

= = = = = = 

What this comes down to is what do Orbit Committers want? 
If we have a maintenance branch, how many of these changes should go in 
that maintenance branch anyway? I suspect not many? Even if all of them 
end up there, that's the safer approach this time. 

Given the (short) timing, unless there's the famed outcry mentioned above, 
I think next week we should start producing "M builds". Then, on 1/25, promote 
that as the R build for projects to use for SR2 maintenance. (Projects could 
use the M build for SR2 RC1, then change to R build, for SR2 RC2.) 

I think this approach minimizes difference between previous R build (used for SR1) 
so minimizes risk ... with fairly small increase in our work :( and some slight 
risk of confusing the heck out of everybody :)  While the risk of breaking someone 
is not large, its probably better to take the conservative approach. 

Other views? 
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev