何时放弃对git-flow /语义版本中贬值的支持
我们通过 git-flow 工作流程，我们坚持<<< a href =“ https://semver.org/” rel =“ nofollow noreferrer”>语义版本。今天，我们讨论了如何处理折旧。出现了两个问题：
A。Semver：可以优雅地贬低次要版本中的功能（例如V1.12.0）吗？
“优雅”的意思是：该功能仍得到支持，但在开发环境中显示了警告。将使用主要版本（如果v1.12.0（v2.0.0）或随后的主要版本）删除支持。
B. git-flow：您如何正确放弃对不建议的功能的支持？
鉴于我们希望在v3.0.0中放弃对功能的支持，而最后2.x释放为v2.14.0。因此，2.14.0 必须支持该功能，而3.0.0 必须删除该功能的支持，因为在4.0.0之前不能删除3.0.0中支持的任何功能。
随后，我们必须在Release/3.0.0分支中删除该功能。但是根据Git-Flow的说法，发行分支只能接受错误修复。
任何建议都非常感谢！
We work by the git-flow workflow and we stick to semantic versioning. Today we discussed how to handle deprecations. Two questions have arisen:
A. Semver: Is it ok to gracefully deprecate a feature in a minor release (e.g. v1.12.0)?
"Gracefully" means: The feature is still supported but a warning is shown in development environment. Support will be removed with a major release (in case of v1.12.0 with v2.0.0 or a subsequent major release).
B. Git-flow: How do you properly drop support of a deprecated feature?
Given we want to drop support for a feature in v3.0.0 while the last 2.x-release is v2.14.0. So 2.14.0 must support the feature while 3.0.0 must drop support for the feature, as any feature supported in 3.0.0 cannot be dropped before 4.0.0.
Subsequently we must remove the feature in the release/3.0.0 branch. But according to git-flow, a release-branch should only accept bug fixes.
Any advice highly appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
tl; dr：实现此目的的一种方法是在最后2.x 发布后，简单地删除
开发的功能。或功能标记删除，并在第一个3.x版本分支上将其禁用。如果您由于某种原因无法执行任何操作，那么在Release上进行操作是可以的。详细信息：
通常，您可以按照将其合并到
开发中，以相同的方式处理删除此功能。唯一的区别是，您需要确保正确的时机正确，以免将该功能删除到开发之前，直到最后2.x 版本创建分支。由开发>开发的下一个版本分支将具有代码，将是3.x版本。如果问题是您不确定最后2.x版本是什么时候发布的，则可以等到您知道，然后将删除代码合并到中，或者考虑功能用配置更改标记删除。然后，您在Release分支上进行更改时，每当您创建3.x版本时，都会简单地切换配置。话虽如此，也许最终并不重要：
请注意，没有git流授权决定您必须做什么的事情。有一个流行的标准 git流>，但是在这里，我使用“标准”一词来表示许多公司用作A 指南的“原始”版本。这不是“”标准，因为没有这样的标准。我认为您指的是关于释放分支（强调我的）：
请注意，即使是“严格禁止”是（强烈）建议的最佳实践。如果您违反了这一规则，就没有git流神会打击您。此外，在您的情况下，可以很容易地认为，在
Release> Release>分支上删除不弃用的功能分支不被视为“添加大型新功能”。 （即使我们忽略添加/删除和新旧/旧之间的区别，也许要删除的功能不是“大”。 分支，出于多种原因。这可能违反了最佳实践，但是在现实世界中，并非总是有可能在100％的时间遵循最佳实践。将GIT流视为有意义的指导方针。请注意，文森特·德里森（Vincent Driessen）在反思的注释中特别指出，他不打算将GIT流变成“教条或灵丹妙药”。tl;dr: One way to achieve this is to simply remove the feature on
developafter the last 2.Xreleasebranch is made. Or feature flag the removal, and disable it on the first 3.Xreleasebranch. If you can't do either of those for some reason, it's still OK to do it onrelease.Details:
Usually you can treat dropping this feature the same way you would treat adding a new big feature by simply merging it into
develop. The only difference is that you need to make sure you get the timing right such that you don't complete the code removing the feature intodevelopuntil the last 2.Xreleasebranch is created. The nextreleasebranch that comes off ofdevelopwill have the code and will be the 3.X release. If the issue is that you don't know for certain when the last 2.X release will be, you could either wait until you do know and then merge the removal code intodevelop, or, consider feature flagging the removal with a config change. Then your change on thereleasebranch whenever you create the 3.X version would simply be toggling the config.That being said, perhaps ultimately it doesn't matter anyway:
Note there is no such thing as a Git Flow Authority which dictates what you must do. There is a popular standard Git Flow, but here I use the word "standard" to just mean "original" version that many companies use as a guideline. It is not "the" standard, as no such standard exists. I think the particular text you're referring to regarding release branches (emphasis mine):
Note even "strictly prohibited" is a (strongly) suggested best practice. There are no Git Flow Gods that will strike you down if you ever violate this rule. Besides, in your case, it could be easily argued that removing a deprecated feature on the
releasebranch is not considered "adding a large new feature". (Even if we ignore the distinction between add/remove and new/old, perhaps the feature being removed is not "large".) Regardless, sometimes new large features do get added to areleasebranch, for a variety of reasons. This may violate best practices, but in the real world it's not always possible to follow best practice 100% of the time. Think of Git Flow as a guideline to work in, when it makes sense to do so. Note that Vincent Driessen specifically points out in the Note of Reflection that he didn't intend for Git Flow to become "dogma or panacea".