best practice regarding version numbers, release names, etc

Has anyone any thoughts about best practice regarding the naming of assembly versions, build numbers, changesets, file versions and so forth

Background (let me know if this is wrong).

a. When I check-in a changeset it is given a unique number and all the files it contains then have their tip version set to this number. For example after checking-in 54 changesets, my next changeset will be 55 and the file it contains (Form1.cs) will have its tip version number set as 55.

b. When I perform a Team build of a Visual Studio Project it contains a collection of files with different tip version numbers; Form1.cs is 55, Program.cs is 36, etc. The team build is also given a unique number, eg 3

c. If I publish myApp (Build | Publish) it is given a publish version number in the form major version, minor version, build and revision number. The revision number is set to increment each time the application is published (by default). Changing the publish version number does not update the Project's assembly version numbers in AssemblyInfo.cs.

d. When I release a Visual Studio Solution it contains a collection of Visual Studio Projects each potentially with different assembly version numbers.

Questions:

1. In terms of version numbers given as major version, minor version, build and revision number. Is the intended purpose of the revision number to identify patches / bug fixes applied to a product after its release see Best Practice (e).

2. Does putting the version number in AssemblyInfo.cs as 1.0.*.3 result in the resulting assemblies automatically being given the Team Build number

3. Where is the publish version information stored Can one write a program to access / update it

Best Practice

a. Using Build | Publish doesn't make any sense when you're using Team System. Best practice is to release products from the Team Build drop directory

b. There is no publishing mechanism in Team Build. Best practice would be to add a Setup Project to your Solution and then add a link from the Project Portal to a HTML file (like publish.htm) that allowed you to run the setup.exe (or msi) in the Team Build drop directory.

c. There is no connection between the publish version and the version numbers that appear in the assembly's file properties (Assembly version, file version, product version). Best practice would be to manually edit the AssemblyInfo.cs file in each Visual Studio Project for each Visual Studio Solution in the Team Build to ensure the version numbers are synchronised before performing a Team Build that might be released.

d. Developers have no control over the version numbers given to changesets, files and Team Builds. Best practice would be to apply a label to the Team Project after successfully performing a Team Build giving the version number as the name and the  build number as the comment. This ties the file versions to the version of the product they produce.

e. Best practice when performing a Team Build intended for release to production is to set the major and minor version numbers as the public name of the release. Once such a release has been published the minor version number should be incremented. Thus if my release plan was 1.0, 1.1. 1.2, 2.0 then the version number defining release 1.1 might be 1.1.567.0 and a subsequent patch would be 1.1.581.1.

It would be nice to get this sort of thing correct given the vast amount of software sold that doesn't seem to have any connect between the marketing name of the release, the development cycle release name, the assembly file version names and what it says in the product's About box. Accordingly, I get very frustrated when trying to tell a Help desk what version of their product I'm using.

Will