版本号怎么办? [英] How to do version numbers?

问题描述

我的公司正在生产产品.它将由SVN版本化.它是一个webapp，因此基本上不会有没有某些功能的版本，因此可以始终将其标记为beta.但是由于它将成为企业产品，所以我真的不希望出现不稳定的监视"事件.那么您将如何进行版本控制? 1.0稳定吗?构建日期应该在版本号中吗?告诉我你们的想法！

My company is building a product. It's going to be versioned by SVN. It's a webapp so basically there will never be a version out which doesn't have some features in them and thus could always be labeled as beta. But since it's going to be a corporate product I really don't want the "unstable watchout" on there. So how would you go about versioning? Is 1.0 stable? Should the build date be in the version number? Tell me what you guys think!

推荐答案

[主要].[次要].[发布]. [构建]

[major].[minor].[release].[build]

主要:这是一项营销决策.您准备好调用1.0版本了吗?公司是否将其视为客户可能需要支付更多费用的主要版本，还是它是当前免费的主要版本的更新?更少的研发决策，更多的是产品决策.

major: Really a marketing decision. Are you ready to call the version 1.0? Does the company consider this a major version for which customers might have to pay more, or is it an update of the current major version which may be free? Less of an R&D decision and more a product decision.

次要:只要 major 递增，便从0开始.公开的每个版本+1.

minor: Starts from 0 whenever major is incremented. +1 for every version that goes public.

发布:每次您达到开发里程碑并发布产品时，即使是内部发布(例如进行质量检查)，也要增加此发布次数.这对于组织中团队之间的沟通尤为重要.不用说，永远不要两次发布相同的发布"(即使在内部).次要++或主要++重置为0.

release: Every time you hit a development milestone and release the product, even internally (e.g. to QA), increment this. This is especially important for communication between teams in the organization. Needless to say, never release the same 'release' twice (even internally). Reset to 0 upon minor++ or major++.

内部版本:可以是SVN版本，我认为效果最好.

build: Can be a SVN revision, I find that works best.

示例
我当前的Chrome:83.0.4103.61

Examples
My current chrome: 83.0.4103.61

这篇关于版本号怎么办?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！