At some level this is just a page of miscellaneous other thoughts I had and didn't really have anywhere else to put them.

Some thoughts on the initialVersion setting value

For any new OS you add, be sure to set this value! At least if you are setting the value of the automaticTrigger setting to true.  Basically, when automaticTrigger is true, the RM will go through and try to create a build for every version number starting with the value in the initialVersion setting up through the most recent version number.  So, for example, if the ScienceTools LATEST builds are currently on version 4053 and you accidentally set the initial version to 3053, you'll get 1000 builds triggered off.  And if you leave it off all together, it will try to create all the builds back to the earliest one in the buildPackage table.  Now, there are only about 20 LATEST tags in the system so only those last 20 will actually get run but it will go through the process of setting up all 1000 and then they will fail on the checkout step as there is no corresponding tag.  For HEAD and release tags, however, the tags are all still there and all the old ones will be built.

Adding a Digit to the Version number

Because of the fact that the Release build version numbers are alphanumeric, the version field in the buildPackage table is a string field and is parsed lexigraphically when using < or > operators.  This causes a problem for HEAD and LATEST builds when the version numbers add a digit (i.e. go from 9 to 10, or 99 to 100, etc) because the new version number (e.g. 100) is lexigraphically smaller than the last one (e.g. 99).  At this point the RM simply stops triggering the builds because it's logic is not showing a new larger version number.  To get around this, you have to do the following:

1. For the class of builds (LATEST or HEAD), set automaticTrigger to false for any builds that have it set to true.
2. Update (or add) the initialVersion setting for all of the build of this package to the new version number (i.e. 100, 1000, etc).
3. Go through by hand (write a script) to change all of the versions numbers for that build in the buildPackage table to have a 0 prepended to them.  Thus if you are tying to go from version 9 to version 10, you'd have to change all the versions to read 01, 02, 03, 04, etc instead of 1, 2, 3, 4, etc.
4. Reset the automaticTrigger setting back to true for the appropriate builds.

I've had to do this for TMineExt (HEAD and LATEST), GRBAnalysis (LATEST only) and ScienceTools (HEAD) so you can see examples of this in the database.