We've the above build number format, and our VCSRevision has hit 65535 and now builds are failing (Built Windows Assembly versions can't have each part of build number greater than 65534)
We're thinking of switching to [major].[minor].[revision / 10000].[revision % 10000] based on comment in http://stackoverflow.com/questions/1188284/net-large-revision-numbers-in-assemblyversionattribute
We hugely rely on the vcs rev for diagnosing issues and qa'ing release distributions. but we've never actually used the build number.
Whatever actual format we do, we need the ability for teamcity to supply our build scripts with these new number formats. Does this require writing a plugin? where do we start? and is there an alternative?
We actually don't use VCS revision numbers. In fact as we are using Git we don't actually have that option.
When we do a release we use Teamcities build number to tag our VCS repositories.
Teamcity has some nice inbuilt tools for doing this and tracking the changes.
As we use a continuous build process we tag test releases with a "TEST AAA" identifier and Release build as "BBB"., where AAA and BBB are the test and release build numbers respectably.
This tag labeling is what makes it easy for us to track our changes , especially in a distributed VCS system where VCS revision numbers could get out of sync.
Obviously we are going to hit the same problem you have when our build hit 65535... but as we have not tied up a version release field with a VCS number we have that to use when and if we need it.