On Jan 11, 2006, at 3:29 PM, Rick Hillegas wrote:
Thanks for pointing me at this piece of the release machinery. I have a naive question: If we have this programmatic way of generating new release numbers and then poking them into test canons, what are we testing here?
Currently, only the last digit in the version has a target for bumping to the next digit. It was created as a convenience for those who want to create snapshots. Working with other parts of the version or the beta flag is still a hands-on process.
At first blush, it seems that we are just verifying that this special release target successfully propagates numbers into canons. What if the metadata test internally verified that the version numbers from the client driver agreed with the values in dnc.properties? Then we wouldn't have to hard code version numbers anywhere: not in the test code and not in the canons. We could remove the metadata canons from the list in the bumplastdigit target.
This would verify that the formatting is internally consistent, but not that the actual version number - as hand-edited into release.properties - was correctly propagated to dnc.properties.
A more appropriate test would be to match the metadata with the information in the hand-edited release.properties. The only problem is that release.properties itself exists only in the source tree. Only its "offspring" - the info properties files - show up in the jars or the build output, and I think its a good idea that the generation of the info properties files from release.properties also be tested.
I agree this is non-optimal, but as it is now the person editing release.properties has a second chance to verify that the version number was correctly generated, even if it is a bit of a pain.
my $.02, andrew
