Community
Participate
Working Groups
In WTP, for our Galileo builds, we recently "moved up" to the latest base builder, R35_M4 and this caused some computed suffixes to not only be different than before, but "lower" than what they were before. This is especially bad for us because the features in question have not changed from our Ganymede maintenance stream (and probably won't). In Ganymede builds we have been using the RC2_34 version of the base builder. And, of course, we want to leave that Ganymede builder the same, to minimize any accidental changes in the build results. So, we hate to just increase the service field in Galileo, just to work around this PDE build "bug", but not sure what else we can do. Any suggestions? Note that while this bug is different, the solution described in bug 208143 might help fix this case too.
> ...and this caused some computed suffixes to not only be different > than before, but "lower" than what they were before. Correction, the qualifiers were not lower, just different.
This is from bug 250942, it could conceivably happen that the qualifiers would drop. You are right to not update your ganymede maintenance builds to use a new builder, at most you would move to a 3.4.x stream builder like R3_4_1, but definitely not a 3.5 basebuilder. (And any builder change still has the same problem). I would argue that changing your builder warrants a version change on everything built with that builder. This is the subject of a short talk I'm giving at EclipseCon and Kim touches on it in here post here: http://relengofthenerds.blogspot.com/2009/02/implementing-composite-repos-in-your.html Even if the source for a bundle does not change, compiler changes, target changes, or other builder changes are quite likely to result in different bits for your binary bundle. There are basically two choices: 1) upversion everything on builder change. This includes the versions of all the bundles even if the source hasn't changed. (Same source + different builder can be different binaries). 2) ship the bytes compiled by the old builder. This is what the platform is doing and is currently accomplished by using p2 mirroring tasks with a baseline to compare against. In the 3.4 timeframe we were doing this by creating our product zips by installing from a repo containing previous builds and the new builds did not overwrite old content. I would recommend (2). I'm not sure what to do with this bug, but let us know if you need tips for doing this.
Thanks Andrew. Very helpful. We'll probably go with '1' but eventually I'll want to learn more about you do P2 mirroring. Thanks.
