持续交付，版本控制和功能分支混乱

我目前正在使用Feature Branch Workflow实施CD。我不清楚什么时候增加版本号。持续交付，版本控制和功能分支混乱

创建新功能时应该增加吗？

所以我们假设我们有版本1.1，并且我要实现一个新功能FB-123。

创建FB时，我应该增加版本吗？

 *---*--- increment build number, now on 1.2.456 
    /increment version to 1.2 
    ---* 1.1

，并使用詹金斯建立后，犯多少？

这一切都真的dep结束于构建号码的用途。内部是否需要帮助解决这个问题？这是否让其他技术人员看到，因此他们可以推断出构建编号的语义发生了什么变化？这值得一读 - http://semver.org/给你一些思考的食物 –

@EvolveSoftwareLtd是的，它是为了解决它。我真的不介意它是否是语义的。 – helpermethod

你使用git吗？功能分支完成后会发生什么？你是否将它合并回主或释放分支？ –

我会考虑使用以下版本的模式：

每一个主要/次要版本将被标上git标签
分支架构 - <major>.<minor>.<number of commits from latest minor>-<feature branch-name>-<sha1>
主模式 - <major>.<minor>（它认为每接受的拉取请求是次要版本）

您可以计算从最近的次要的提交次数

git rev-list HEAD ^<latest minor tag> --ancestry-path <latest minor tag> --count

该模式将允许您从版本名称派生：

2016-09-01 09:37:57

回答