软件版本管理

ranjh

大家好！我向各位求助下有关软件的版本控制方面问题。

目前我公司有产品和项目，项目是用产品实施的，但是各个企业不同，二次开发有很多的不一样，为了做个通用的产品，想把各个项目中的好的东西集合起来作为下一个产品的需求，再开发新的产品。

但是现在要求能够把各个项目和产品主线也给管理起来，并且把各个变化的地方也体现出来怎么办？（我是做ERP的用Oracle 的开发工具开发！~）


本人MSN可以联系！

海的女儿

最好你们能用配置管理工作，如vss、cvs之类的

hongtang

海的女儿

hongtang:
是说我么？我不是告诉大家偶要潜水一段时间，这不刚回来嘛，呵呵~

songfun

版本号由二至四个部分组成：主版本号、次版本号、内部版本号和修订号。主版本号和次版本号两个部分为必选。内部版本号和修订号两个部分为可选；但是，只有在未定义内部版本号部分时，修订号部分才为可选。所有定义的组件必须是大于或等于 0 的十进制整数。元数据将主版本号、次版本号、内部版本号和修订号组件限制为 MaxValue 最大值 - 1。

版本号的格式如下所示。可选组件显示在方括号（“[”和“]”）中：

主版本号.次版本号[.内部版本号[.修订号]]

应根据下面的约定使用这些部分：

Major：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。
Minor：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。
Build：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。
Revision：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。
程序集的只有内部版本号或修订号不同的后续版本被认为是对先前版本的“快速修复工程”(QFE) 更新。如有必要，可以通过更改配置中的版本策略使内部版本号和修订号生效。

toney228

请问斑竹，有没有软件版本的范例或更详细的资料。

Joan2005

收藏。。

luoyear

我觉得你描述的问题表面上是一个配置管理的问题，但更深层次是没有理清客户话定制和产品化（平台化）的关系。
以产品为主线，设置一个产品经理。任何一个客户话的项目需求需要纳入产品，需要走变更流程，由项目经理向产品经理提出，并由CCB决策是否并入产品并实施开发。当然，这项工作也可以是先是该项目的客户话行为，在项目完成后，项目经理觉得有必要提交产品作为产品的组件。【这一点激励措施很重要，项目经理为产品化是会花费额外的人力的，所以必要的激励措施鼓励这种产品化是很重要的。】
每个项目启动时候，它基于产品的哪些组件先确定，然后由此拉出分支，在自己的分支上就行版本的开发。这里又涉及到了如果该项目基于的产品组件升级了怎么办？这个需要项目组进行决策，是并入产品组件已经升级的内容，还是维持原有的开发基础不变？

ting_yt2

我们部门遇到的问题和LZ一样  为了解决这个问题 曾经花了大力气整合了一个产品出来 可是后来客户化的东西太多 导致那个“产品”基本处于闲置状态   目前又回到了原来的状态

luoyear说的很不错 可是实际执行似乎不那么简单 纳入产品需要人力需要时间 且表面看起来（表面！实际当然不是这样）无法产生经济效益  所以这项工作一直都被忽略！

stilldeeppool

关于版本管理.我认为大多数人可能太过于迷信CVS等配置管理工具了
当然并不是指这些东西没有用.实际上是我们大多所处的开发规模以及版本管理需求还用不到如此专业的需求
而需要CVS配置的.往往都是有专门的职业:版本管理人员/配置管理人员 来负责

我尝试过在一个十几人的团队中负责CVS的管理工作,坚持了半年后.就放弃了
一是我们目前的开发人员还没有这样的开发习惯
二是CVS还不能真正贴近我们这样小团队的需求

现我们单位有近三百人的开发团队.而我们的开发是以产品来划分项目组的.比如像我们 属于一个视频服务器开发小组.小组成员有九人.
我们扔掉了CVS.根据我们版本的现状与需求.我们自己定义版本管理规则.包括版本的提取.备份.发布.开发人员管理自己的VSS
测试人员备份版本和代码

刚搭建不久.用起来相当的不错.
为什么呢?
这是真正贴近于我们自身的版本管理需求的
我们也考虑目前管理中的一些不足,以后会抽时间来开发自己的版本管理工具

如果楼主有需求.倒不妨可以借鉴一下我们的这种模式.相应的PPT文档你可以找我要

[ 本帖最后由 stilldeeppool 于 2006-9-18 11:11 编辑 ]

dihoboa

基于同一源码的多产品线开发用CC比较好。

andrewchou

CC比较复杂。
这个问题也没有非常好的解决办法，不过按照版主的方法可行，但经过几个这样的周期后，产品的版本也会比较混乱的

changlang530

版本需要统一，版本的管理也很重要。

yxs2008

很荣幸看到你在软件版本管理一文中留的言,对你们这种模式非常的感兴趣,能否麻烦你把你们这种模式的简介与PPT与我分享.
EMAIL:yangshuangxiang@163.com

dingle_lily

我觉得很多的时候，由于赶进度或时间有限，很多的项目都会忽略了版本管理（尽管知道版本管理很重要），尤其是开发版本的管理。
现在很多的版本管理都是依赖CVS或SVN，个人感觉，当代码或程序回退是比较麻烦。
CVS或SVN的版本是针对每个具体问题的（听说可以对一个完整的程序代码打标签，个人没有尝试过，也只是听说，但是效果如何，需要验证一下了。）
因此，这个时候，测试版本的管理就尤其重要。
但是，需要专人进行版本的管理。而这项工作比较繁琐：不仅需要对代码进行管理，还需要记录没有版本所对应的内容（缺陷修复，涉及到的功能等）


不管怎么样，还是需要找到适合自己项目的方式。也许开始的时候比较困难，但是，在进行的过程中经过不断地修正和改进，会得到一个比较好的结果的。

wjgemini

对于一个盈利来源主要在项目,客户化订制比较高的企业来说,要做好这个工作非常难. 至少我觉得是这样. 售前在打单的时候通常大包大揽就接了,完事后留下一堆坑, 这些坑需要慢慢梳理,可是很多东西都不是能够划入产品的. 即便划入了产品, 其上线压力也会导致在项目开发的过程中无法准确的将feature纳入到产品中,而事后可能由于资源,时间的因素没有办法重新调整. 也有可能代码的重构已经非常困难. 总之这个问题非常棘手,需要相关的领导有这样的意识. 现在大多数的情况是,公司想要做好产品,可是由于项目的压力做啊做啊就变成项目了. 导致许多东西不能很好的做成产品.

从代码维护的角度上来说, 首先是需要一个类似cvs,svn之类的工具来维护. 其次,对于产品和项目的关系, 可以将产品类特性提交在某个module上,比如A. 而项目的个性化代码提交在单独的module上,比如B. 在推出产品发布的时候,使用A的内容直接编译发布. 而在适应项目的时候,使用A+B的方式编译并发布. 这个对管理的要求比较高,对产品经理划分定义产品级别和项目级别的能力也要求很高,其实说白了就是归纳的能力.

这个我只是举个例子, 也不知道对不对,大家随便看看不要骂我哈!  顺便说一下, 我发现现在很多产品经理都是对版本一点概念都没有的.

zxq0101

对这个感兴趣，麻烦也发给我一份，不胜感激，275700641@QQ.COM

shpp_xy_81

回复 10# 的帖子

我现在正在搞版本管理这块的内容，对这个东西比较感兴趣，能不能发给我一份，shpp_xy_81@163.com谢谢

wcp_856

好久以前的帖子了，不知道还有没有。。。
wcp_856@163.com

caixiaoyan6

我现在也在烦恼这个事情