问题标签 [release]

情况：我们的测试版已结束，1.0 版已发布到多个客户站点。团队 A 已经忙于开发 1.1 版，该版本将进行增量错误修复和可用性调整，而另一个团队则致力于 2.0 版进行大规模更改，其中产品的核心可能已经完全重新设计。现在，为 1.1 所做的大部分更改都必须在某个时候进入 2.0，而在 2.0 分支中进行的一些错误修复实际上可能需要安排在较早的版本中。问题在于，由于 2.0 有根本的不同，因此 1.1 的任何更改都不能在没有手动转换的情况下合并，反之亦然。

我的问题：在这种情况下，将合并冲突和重复工作降至最低的最佳修订控制实践是什么？如何确保我的团队在修订控制问题上花费尽可能少的时间和精力，同时仍向客户提供定期补丁？

我们有标准的 Subversion 主干/分支/标签布局。我们有几个用于中长期项目的分支，但到目前为止还没有一个发布版本。这正在快速逼近。

我们应该吗：

1. 将发布分支和项目分支混合在一起？
2. 创建发布文件夹？如果是这样，有没有比发布更好的名称？
3. 创建一个项目文件夹并将当前分支移到那里？如果是这样，还有比项目更好的名称吗？我在其他存储库中看到了“沙盒”和“尖峰”。
4. 完全是别的东西吗？

所以我有大约 10 个与 mvc 应用程序一起使用的短 css 文件。有诸如 error.css login.css 等......只是一些非常短的 css 文件，使更新和编辑变得容易（至少对我来说）。我想要的是可以优化 if else 分支而不是将其合并到最终位中的东西。我想做这样的事情

我将有一个 msbuild 任务，它将合并所有 css 文件，最小化它们以及所有这些好东西。我只需要知道是否有办法删除最后一位中的 if else 分支。

这是一个哲学问题。我正在向我的软件添加一个小功能，我认为大多数用户都会使用它，但他们使用该软件的时间可能只有 10%。换句话说，该软件在没有它 3 个月的情况下还可以，但有 4 或 5 个用户要求它，我同意它应该在那里。

问题是，由于我正在使用的平台的限制（可能是我大脑的限制），“我能做的最好的”仍然有一些非关键但明显的错误 - 假设编码的功能是可用的但在某些情况下“有点不稳定”。

该怎么办？有 90% 的功能真的“聊胜于无”吗？我知道我会收到一些我无法修复的错误报告：我应该告诉客户什么？我应该接受未答复的功能请求或未答复的错误报告吗？

使用我的多项目 pom 时，我在运行 release:prepare 时遇到错误。项目设置没有什么花哨的，之前的每个发布步骤都运行良好。我得到的错误是：

知道它来自哪里以及如何解决它吗？

（很抱歉重复的帖子 - 第一次被关闭是因为我没有将其表述为可以回答的问题。我希望现在可以了。）

编辑
Maven 发布插件负责版本处理本身。因此，当我检查 subversion 存储库中的路径时，路径还不存在。

编辑 2
@Ben：我不知道服务器版本，但是客户端也是 1.5.2。

编辑以提高清晰度

Scrum 建议您将开发拆分为多个 sprint。每个冲刺都是固定的持续时间。在每个 sprint 结束时，您都会询问客户是否应该发布该软件。如果他们说是，您将执行发布冲刺，在此期间您会​​连续执行所有您想做但成本太高的任务，例如外部用户测试、性能负载测试和签核、刻录 CD（如果相关） ，编写以用户为中心的文档等

在我当前的项目中，我们刚刚完成了我们的第一个发布冲刺。我们发现我们失去了 scrum 的很多优势，例如烧毁（因为很多事情都是在修复微小的调整或暂时从站点中删除安全性以便进行负载测试），一个明确的目标是要完成多少工作接下来完成等等。基本上，发布任务太接近消防，无法通过普通的 scrum 工具轻松跟踪。

在发布冲刺期间，其他人使用了哪些方法，您发现应该避免哪些陷阱？

我在线分发软件，并且总是想知道是否有更好的方法来更好地定义版本号。

让我们在答案中假设 ABCD。你什么时候增加每个组件？

您是否使用任何其他版本号技巧，例如 D mod 2 == 1 意味着它仅是内部版本？

您是否有带有自己版本号的 beta 版本，或者您是否有每个版本号的 beta 版本？

如果您有一个发布库和应用程序的项目，您如何处理两者之间的版本号。

示例：您的项目提供了一个库，可将不同的文件格式相互转换。该库已发布以包含在其他应用程序中。但是您还发布了一个命令行应用程序，该应用程序使用该库并实现该功能的接口。

库的新版本会导致应用程序的新版本（以利用所有新功能），但应用程序的新版本可能不会触发库的新版本。现在如何处理版本号：完全独立还是应该以某种方式依赖库和应用程序版本？

When receiving a bug report or an it-doesnt-work message one of my initials questions is always what version? With a different builds being at many stages of testing, planning and deploying this is often a non-trivial question.

I the case of releasing Java JAR (ear, jar, rar, war) files I would like to be able to look in/at the JAR and switch to the same branch, version or tag that was the source of the released JAR.

How can I best adjust the ant build process so that the version information in the svn checkout remains in the created build?

I was thinking along the lines of:

• adding a VERSION file, but with what content?
• storing information in the META-INF file, but under what property with which content?
• copying sources into the result archive
• added svn:properties to all sources with keywords in places the compiler leaves them be

I ended up using the svnversion approach (the accepted anwser), because it scans the entire subtree as opposed to svn info which just looks at the current file / directory. For this I defined the SVN task in the ant file to make it more portable.

Not all builds result in webservices. The ear file before deployment must remain the same name because of updating in the application server. Making the file executable is still an option, but until then I just include a version information file.

Refs:
svnrevision: http://svnbook.red-bean.com/en/1.1/re57.html
svn info http://svnbook.red-bean.com/en/1.1/re13.html
subclipse svn task: http://subclipse.tigris.org/svnant/svn.html
svn client: http://svnkit.com/

我有一个包含许多 C# 项目的大型解决方案。当我第一次打开解决方案并按 F5 时，出现如下编译错误：

错误 3 找不到元数据文件“C:\Users\david\Documents\VS.Projects\CeoTrunk\Ceoimage\bin\x86\Release\Ceoimage.dll”。

我正在编译解决方案和产生“调试（任何 CPU）”错误的项目，并且很长时间没有选择“发布（x86）”。也许几个月。在我第一次为“调试（任何 CPU）”构建解决方案后，这些错误就消失了。如果我关闭解决方案并再次按 F5，问题会再次出现。

这个“Release (x86)”的残余藏在哪里？我该如何摆脱它？为什么它总是回来？