请问各位朋友在开发软件过程中对于软件版本是怎么控制的？是否有自动化的版本控制工具么？
---------------------
我们一般都是通过在AssemblyInfo文件中修改版本号来实现，对于每个版本号和历史的控制都是通过TFS备份历史版本并手动改写版本号进行控制，请问有没有什么自动化的工具来实现或者其他办法呢？
------解决思路----------------------
感觉是缺少一套build机制，一般版本号是定义在 build 脚本里的（build 脚本也可以从CI 定义的环境变量中取），开始 build 的第一步就是把版本号写进 AssemblyInfo 文件中，然后 msbuild，之后运行单元测试，还有打包发布之类的。这些东西应该做成一键完成的。同时支持手动和自动流程。
手动流程就是自己修改build脚本中的版本号，build执行后没有错误，选择在VCS 中加 tag。自动流程就是 CI build 的时候也可以使用一些信息影响版本号，会覆盖 build 脚本中的定义，然后 build 成功结束后 CI 自动对 VCS 加 tag（daily build 可以不进行 tag，milestone 需要 tag）。
版本号肯定是自己定义的，一般类库 / 框架最好使用 semver 规范，版本号主要体现兼容性。其它产品的话版本号也可以体现别的特征。
一般说的版本号是产品版本，比如 1.6.1-beta2，在自动 build 的过程中，还需要生成其它版本号：
程序集版本（AssemblyVersion）使用前两位，就是 1.6.0.0，保证 1.6.5 可以直接替换掉 1.6.1，而 1.7.x 不能直接替换 1.6.x。
文件版本（AssemblyFileVersion）体现 build 日期 / 序号，比如 1.6.20918.1 表示这是 1.6 版本在 9月18号的第1次build，这里那个 20918 是微软的日期方式，表示这个产品的第二个年头中的9月18号。便于在 CI 中查找记录。
代码版本（AssemblyInformationalVersion）体现实际的产品版本定义以及 VCS 中的 revision，比如 1.6.1-beta2+4340ce4，便于在VCS中查找记录。
还有AssemblyConfiguration可能也要根据 build 的参数修改。
------解决思路----------------------
Continuous Integration 持续集成，主要就是用来 build 的，里面定义触发器，定义 build 步骤，定义build 输出的结果。它可以进行 daily build，或者代码有提交就可以build，让开发人员及时了解 build 结果。TFS 是集成了这个功能的（它集成了 VCS，CI，Issue Tracker）。不过我不喜欢 TFS，CI 工具用的 TeamCity。
------解决思路----------------------
使用好版本管理系统，说明了团队开发的正规性。它是文档（程序源代码）版本变化的沟通工具，在几个人以上共同开发软件时就非常重要，其实单个人搞开发时也重要。只要是需要设计创造的活动，对文档版本管理系统都非常依赖，因为这样就可以大胆地进行实验——将来可以比较各个版本甚至版本回滚。
如果在对外交流时，别人说道“你们是用什么版本管理工具？”，就是指这个。包括 GIT、SVN、TFS 都是。而 GIT 主要适合那些炒作开源项目的人，SVN主要适合敏捷开发的团队，TFS的特点是它微软自家的。
------解决思路----------------------
就是SVN，GIT呗。
简单些的系统可以用vss，和vs集成。
这些是管理源代码的“版本控制工具”。源代码的每一次提交，都是一个版本。
而把源代码编译并正式发布产品，产品的版本，与此版本是两回事。