这是一个创建于 1250 天前的主题，其中的信息可能已经有所发展或是发生改变。
1 、项目上线后发现了 bug，影响很小，但是领导要求要改，这种情况一般是马上修复还是下个版本修复？
2 、项目上线后发现缺少了某个功能，影响很小，但是领导要求马上解决，这种情况一般马上增加，还是下个版本增加？
3 、以上两种情况，如何控制版本号？
4 、前后端和 app 版本号是否要分开？
我目前的小公司是集团子公司只有几个人，但是现在要开始做集团的业务系统，初期版本都是单人负责，验证业务可行后会不断迭代功能，后面还要将多个系统互联互通。
初期版本已经上线，但是问题很多，这些问题都由系统的使用人员在群里反馈，然后复制系统的人直接修改，现在系统一多就乱成一锅粥了。
 |
1
AoEiuV020 2021-07-02 11:22:44 +08:00  1
1 和 2 自己觉得做不了主就让领导决定，没特别要求一般是下个版本修复，如果领导说的马上解决是要马上看到结果，那当然是立马更新版本了，
3，只要发包就改版本号， 4，各端版本无关， |
 |
4
kop1989 2021-07-02 11:30:53 +08:00
1 、2 并不是技术问题。
3 、更新就是新版本。 4 、每个项目的版本号独立。但要做好兼容性问题。 |
 |
5
raycool 2021-07-02 11:34:11 +08:00
你这个不是应该是做好版本管理就行了么？
BUG 是否立即上线就看你和领导之间的权衡了。 |
 |
6
paradoxs 2021-07-02 11:34:14 +08:00
谁有权命令你就听谁的。 不然等着换工作。
|
 |
7
jiayong2793 OP @kop1989 这些都不是技术问题，并且我也不是程序员，但现在公司的项目很乱，领导要让我管管，我就想着目前集团的发展，后面肯定是大公司的各种流程，但我没在大公司待过不知道流程怎样的，所以发到这个节点问问
|
 |
8
yexiaoxing 2021-07-02 11:41:14 +08:00
3. 版本号不都是自动生成的，控制啥。
4. 不同的 project 就有不同的版本号。 |
|
9
kop1989 2021-07-02 11:49:14 +08:00
@jiayong2793 #7 你可能没理解。我所谓的“不是技术问题”，是指这并不是技术部门通过管理来决策的。换句话说，1 和 2 根本就由不得你来规划。
比如集团领导说希望你们马上添加一个功能。你告诉领导等下个月的 release，你基本上就可以收拾东西了。 |
 |
10
chenluo0429 2021-07-02 12:00:16 +08:00
1 和 2 其实是一个问题，生产环境的问题是否需要 hotfix，需要结合问题严重性，复现难度，修改难度，正常发版频率等来综合考虑。
3. 只要发布了，版本号就要便变更。 4. 版本独立，回溯问题的时候能够找到特定时刻每个端的版本号就可以了 |
 |
11
mxT52CRuqR6o5 2021-07-02 12:07:19 +08:00 via Android
曾经的工作经验，看要求改的是多大的领导，像我带过的那家大公司，很高级别的领导提出的意见，不过是不是 bug，直接最高优先级处理
|
 |
12
hyb1996 2021-07-02 12:09:40 +08:00 via Android
客户端发版本需要权衡成本(开发修改的人力和时间，联调的时间，重新做上线测试的测试人力和时间，对其他需求的时间挤压)、风险(改动的大小、影响面、可能引入的新问题)、收益(问题的影响面、严重情况、是否为核心路径、核心体验)、是否为历史问题。如果是小概率、影响程度小的问题，一般可以跟下个版本；改动很大、修改风险高的问题，也可以跟下个版本以经过充分的测试暴露问题；本个版本引入的新问题尽量跟这个版本修复，原则是收殓问题；老板遇到的或者特别重视的可以紧急修复，但也要反馈相应的成本和风险给到老板。
|
 |
13
cking 2021-07-02 12:14:47 +08:00
如果影响不是很大 一般都是下个版本 如果影响很大 那就直接 hotfix
|
|
14
jiayong2793 OP @kop1989 这不就是领导自己定规矩，然后自己先打破吗？
|
|
15
kop1989 2021-07-02 14:05:35 +08:00
@jiayong2793 #14
1 、程序、流程是死的，人、业务是活的。 2 、公司的唯一目的就是股东利益最大化。 3 、规矩，是用来固定下属的操作范围，从而保障利益的，如果规矩与利益冲突时，必然保障利益。 所以你的问题 1 与问题 2，其实压根就和正常的运营规范不沾边。停留在书本上谁都知道应该定期发版，灰度测试。但现实业务中又有几个“理想情况”呢？ 所以你现在应该做的是： 1 、一个理论上的稳妥流程。非特殊情况用此流程。此流程最保守。 2 、一个紧急处理流程。用于处理部门内的紧急情况，比如影响业务的 bug 等。进行紧急修复。此流程最激进。 3 、一个最优先处理流程，在需要敏捷处理的需求到来时，使用此流程，此流程的安全程度介于 1 、2 之间。 但无论哪个流程，都要保证服务器端和客户端程序版本可以无痛回滚。 |
 |
16
bianxiuyan1993 2021-07-02 14:18:50 +08:00
如果是定成 bug 的话，基本都是紧急处理上线
|
 |
17
TypeError 2021-07-02 14:24:24 +08:00
小版本号就是解决问题 1 的，问题 2 看话语权，话语权强的团队就可以推到下个大版本一起开发，这样开发测试上线时间都充足，少出幺蛾子
|
|
18
jiayong2793 OP 1
@kop1989 领导的意思是要确定一个流程来规范现在版本混乱的问题，但是领导自己又非常随意，另外他自己也开发维护了一个重要的业务系统，我根本不知道那个系统发生过什么
另外，系统根本没有测试就直接发版了，上线了，用户发现问题了我才知道，并且这种工作方式是这个领导带领这个团队养成的作风 |
Select Language