Being in software development myself, I have to interject and poopoo this statement. When you are developing something to be released, like a revision to software, you change it along the way during testing before releasing it. It could be new bugs that arose from changing other things. This would not add to the revision number, it's just fixing problems that were found during testing of the new version.
You are partially correct. As soon as the product leaves the developers hands and is sent off to be packaged in a nice user friendly installer / compressed and is tagged with a signed certificate, that software is branded with a revision number. If a problem is found in that rev and is sent back to development, it will no longer come back with the same rev number. That's the whole reason of such long rev numbers like 4.7.0.75 and also build numbers. If a software company did not do this, they would be in for some really big problems.
So yes, a developer can change the code as much as he wants, as long as they do not add new features to it and only fixes bugs they find during compiling the code, then yes the rev number will be the same. But once the packager gets a hold of it and adds all of the legal agreements that people have to check off and such and then signs it with a Verisign cert (liked the leaked version was), then it's locked to that rev.
Small development house may have their developers do everything from coding to packaging the code. Larger one (like RIM) have coders who only code, a department to compress and package the final code for installation and then a QA department.
