Difference between revisions of "WTP/Build/Accounting for history during builds"
m (WTP/Build/Accounting for History during builds moved to WTP/Build/Accounting for history during builds: correct title case)
Revision as of 23:13, 12 October 2010
By using p2 (and related tools) during builds, it is possible to better account for history when delivering builds of our code.
In short, if a bundle has the exact same version as it did from previous builds, then that previously built bundle should be assumed to be the same, and that previously built bundle reused and it be delivered instead of the recently built one. This is kind of counter intuitive, but this is the way a p2 based install would work; if someone already had that bundle installed, with the exact same version, then they would never get a new one installed.
Of course, the immediate problem is that sometimes the byte codes do change even though the source code doesn't change (so hence the version doesn't change). In general this happens because we version code based on our source, but other factors can effect the built code ... for example, a constant in a pre-req might change, the compiler might change, etc. For a complete overview and introduction, see Andrew Niefer's blog entry.
In particular, for WTP, we have had a recurring problem, where a feature version (with its build-time computed suffix) stays exactly the same, but the contents of the feature changes (and then, the problem is actually, it is not noticed until weeks or months later). This is due to the computed suffix not reflecting enough significant digits to fully account for its contained bundles; see bug bug 208143. The only solution for this bug, since we do not want to make the suffixes extremely long, is to detect the problem, and take appropriate action. While it'd be ideal to do that "real time", during the build, the next best alternative is to at least detect it shortly after a build, and correct it before the code is delivered.