补丁管理带给我的困扰

xsnzhq

补丁的管理让我觉得和你头疼，希望大家能给予帮助：
1、版本号应该和补丁号一致吗？（就是如果版本号为ABC1.0.3,那么补丁号为ABC1.0.4按照其顺延吗？如果不一致，是应该如何管理呢？补丁号一般都是怎么名命名的呢？那版本号呢？）
2、补丁如何管理？（什么情况算作补丁？修改问题、需求变更、新增功能？希望大家帮忙界定。还有就是什么时候可以算作是补丁，而什么时候又算作是升级呢？这个实在不好界定阿。）
3、补丁以什么形式打到客户方？（是存在问题就打一个小补丁到客户方？还是每次给客户时都是一个完整的版本？还是先打几次小补丁，等一定时间后将给客户发一个完整版本，也就是收集一段时间的补丁？那种会好一点呢？）
关于补丁的问题存在很多疑惑，希望大家指点。谢谢！

xsnzhq

大家怎么都不回答呢？麻烦大家帮帮忙！ 这个问题很棘手！

xsnzhq

经过一段时间的考虑，我也对所提的问题有了些思路，对于版本号和补丁号方面稍稍了解一点。至于版本号是如何定义，采用大版本号.小版本号，或是再加上迭代名称，或是采用日期，这都要看各自的公司了。版本号和补丁号的区分可以使用一些标记，就可以将其区分开。
但是比较困惑的还是如何界定何时是补丁何时是版本升级。还需要大家帮助！

chengxq

前几天没有细看这个帖子，今天细看了一下，ls的帖子说明你的思路是正确的
至于版本管理是根据每个公司的定义不同而不同的，如果公司有这方面的定义，直接去参考，如果没有，请提交，让相关部门去定义，因为这样的问题，对于做产品的公司应该是比较普遍的问题。
关于“但是比较困惑的还是如何界定何时是补丁何时是版本升级。还需要大家帮助！”
个人认为，关于做产品的软件公司，如果对一个产品频繁的打补丁，那么客户的满意度肯定会下降，所以对补丁的发布还需要考虑，可以在下次版本发布的时候一起做，对一些严重的，而且出现频率高的问题，补丁要及时发布，对于补丁和版本升级个人认为还是属于公司的定义。
总之，一切都是为了提高客户的满意度！说白了，只要客户满意就行，虽然可能我们自己知道这里面问题一大堆，但这不重要，重要的是客户的满意程度！

xsnzhq

您的回答给了我很大的启示，先谢谢您。明白您对于产品所说的补丁的解释，您说的是很有道理。作为产品，不能轻易的打补丁，这样不但客户满意度下降，自己公司的版本控制也有可能出现问题。但是还是很希望你能说说如果是项目呢？是不是客户很急切解决并且文件改动不多的时候就是可以定义为补丁呢？相反，如果是客户不是很急切或是尽管客户很急切但是文件改动很大的时候就应该打一个完整的版本呢？问题很罗嗦！

chengxq

原帖由 xsnzhq 于 2008-9-8 17:49 发表
您的回答给了我很大的启示，先谢谢您。明白您对于产品所说的补丁的解释，您说的是很有道理。作为产品，不能轻易的打补丁，这样不但客户满意度下降，自己公司的版本控制也有可能出现问题。但是还是很希望你能说说如果 ...

是不是客户很急切解决并且文件改动不多的时候就是可以定义为补丁呢？
如果客户很急切，影响了客户的满意度，对这种问题第一，及时，准确的完成，如果这当中我们自己也发现了改动量不大，但可能将来用户不满意的bug
也要一起作为打补丁的形式修改掉，这个时候，一定要打补丁，因为打补丁了，就有了版本号，客户知道我们的版本控制，否则------
如果是客户不是很急切或是尽管客户很急切但是文件改动很大的时候就应该打一个完整的版本呢？
对于这个问题，个人认为先不要着急，要权衡利弊！有大家讨论的形式来决定如何处理！同时最好也和客户说明
现在存在的问题，以及相关的利益关系，能够得到客户的理解。至于说更新版本号，如v1.0.1更新之后是v1.1还是
v2.0还是v1.0.2这是公司的版本定义的问题。

xsnzhq

感谢您帮我解决困惑！您的回答给了我很大的帮助！

chengxq

原帖由 xsnzhq 于 2008-9-9 17:41 发表
感谢您帮我解决困惑！您的回答给了我很大的帮助！

谢谢！