SVN:保留buggy发布版本的标签有效吗?

好吧,为什么不呢。首先,标签只是一个具有不同名称的分支。从技术上讲,两者没有区别。区别在于你如何对待他们。

从未 修改-这是你和你的发布程序可以回答的问题。没人能说你错了。

我根本不使用标签,我们把发布的版本放在主干上,并在上面添加日志注释,这样我们就永远不会修改发布的版本,我们必须发布最新代码的新版本,但这符合我们的产品套件(否则我们会陷入成百上千个标签的泥潭),而且客户永远不会想要旧版本——他们总是得到最新的。

编辑: 我认为,如果你想拥有完整的可追溯性,你需要的不仅仅是一个标签分支,它有一个,而且只有一个版本。在这种情况下,每个标签的头部修改应该仍然足够您使用一个损坏的版本,该版本可以很快得到修复。它还可以提供使其具有“发布质量”所需的修复的跟踪。

在最佳实践方面 ,您应该已将错误修复提交到标记为4.3.0GA的分支。然后从固定分支创建一个新标记。当然,根据最佳实践,这也假设它是从某种分支/release-4.3维护分支标记的,而不是从一个主干标记的,该主干自标记发生后从星期天起经过了六次修改。你也会 保持 为子孙后代的童车标签,因为这是标签概念的重点。

颠覆没有法律,一个分支只是一个分支,所以你可以做任何你想做的事。尽管在这种情况下,ofc应该将您定义为首席程序员、发布经理或整个团队,即负责做出决策的人。为RCS/VCS/SCM垃圾制定一个策略对于任何非琐碎的项目来说都是明智的。

最好的做法是每个发布至少有两个分支。

一个分支用于维护您发布的代码,另一个分支是您实际发布的代码的从不写入的“标记”。用户可以下载的任何版本都有一个标签,每个主要版本都有一个维护分支。如果提交属于trunk和release分支,那么SVN手册和Google会告诉您该怎么做。我称之为樱桃采摘和再基地,但你可以猜到我从哪里来;)

在我看来,A和B有一些道理。

我倾向于站在 A :

嗯,标签应该是时间线标记,显示特定版本或发行版的代码库状态。即使那个版本是错误的,这是什么出货,你应该有一个记录,以防你需要结帐和付款 故意 重现该版本可能为客户机、服务器或您所拥有的东西造成的错误。

有人可能会通过签出那个标记得到一个bug版本的代码库,但是很多标记不也是bug修复吗?你不应该陷入 决定你在风投公司做什么。存储在Subversion外部的发布日志应该有助于最小化错误签出。

我的经验法则是:如果新的代码发布了,它会进入一个新的标签。