At some level this is just a page of miscellaneous other thoughts I had and didn't really have anywhere else to put them.
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.
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:
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.