Questions tagged «versioning»

我目前管理的图书馆有很多公共用途，并且我对语义版本化有疑问。我想重构该库的一个相当重要的部分，该部分执行不正确-始终执行不正确。但是，这样做将意味着更改公共API，这是一个重大决定。 我要进行的更改围绕如何使用迭代器展开。当前，用户必须执行以下操作： while ($element = $iterator->next()) { // ... } 至少在PHP的本机Iterator接口中，这是不正确的。我要替换为： while ($iterator->valid()) { $element = $iterator->current(); // ... $iterator->next(); } 类似于： foreach ($iterator as $element) { // ... } 如果您查看Tom的语义版本控制指南，他清楚地指出，对公共API的任何更改（即那些不向后兼容的更改）都应证明是主要版本的合理性。因此，该库将从1.7.3跳到2.0.0，对我来说，这是一个太远的步骤。我们只是在谈论一个已修复的功能。 我确实有计划最终发布2.0.0，但是我认为这是您完全重写该库并实现了许多公共API更改的时候。引入此重构是否需要发行主要版本？我真的不知道它是如何工作的-我更愿意将其发布为1.8.0或1.7.4。有人建议吗？

18 versioning  release-management  semantic-versioning 

在繁重的开发期间，数据库架构会快速且连续地发生变化，并且随着我们每周对beta版本的推动而来，架构已发生了如此大的变化，以至于唯一明智的选择是删除所有我可以并且可以从我的开发数据库中复制新版本。显然，一旦启动，这是行不通的，因为破坏生产数据是灾难的根源，所以我想知道那里有什么策略来管理从一个版本/修订到另一个版本的数据库模式更改？ 我发现或经历过的一些： 直接从一个数据库到另一个数据库的nuke-and-dump（我现在在做什么） 使用通过脚本或手动运行的SQL语句维护UPDATE.sql文件。 在活动数据库中维护具有相应“ db-schema-version”值的update.php文件 第三种选择似乎是最明智的选择，但是仍然存在构造错误的SQL查询使中间脚本失败的可能性，从而使数据库处于半更新状态，因此需要还原备份。 看来这是没有问题的，但是确实发生了，因为我们作为一个团队，我们使用phpMyAdmin，我什至不能依靠自己记住复制执行的SQL语句以粘贴到update.php文件中。导航到另一页后，我必须手动重新编写SQL语句，或者撤消更改并再次执行。 我想我希望找到一种不会影响我们已建立的开发工作流程的解决方案？

17 database  versioning  push 

几个月前，我开始担任初级程序员的工作。我们正在研究的系统已投入生产约2年。我没有参与系统和设计的乞讨。 我注意到的一件事是，系统主要版本已经是11.YZ。根据我在其他系统和库上的使用经验，我不记得看到如此快的产品碰撞主要版本的情况。有些产品已经在1.XY中使用多年，并且仍在接收功能和错误修正。 假设正确使用了语义版本控制，这是否表明系统设计不佳，因为它几乎每四个月进行一次重大更改？

16 versioning  semantic-versioning 

我所看到的所有语义版本控制示例都显示了3个使用中的组件。不超过2个句点字符。在$DAYJOB，我们在发行版号中使用4个组件： 5.0.1.2 语义版本允许吗？ 作为一个更高层次且更具争议性的附带问题，这真的很重要吗？我开始认为实施语义版本控制可能是一个好主意，但最终像PCI这样的实体会覆盖它。 我应该在我的PCI评论中弄清楚。问题在于，当主要和次要组件发生更改时，审核及其成本会受到影响，而这不一定是真正的新功能。例如，如果引入了与付款相关的功能，我们将为PCI分配次要数字。但是，如果我们在gui中添加了与某物相关的全新功能，则不会。仅补丁程序更改。因此，在这种情况下，作为开发人员，我们实际上没有发言权，因为其他人会做出这些决定。

16 versioning  semantic-versioning  pci 

在URL中指定REST API的版本是很普遍的，特别是在路径的开头，例如： POST /api/v1/accounts GET /api/v1/accounts/details 但是，我还没有看到将版本与每个API关联的任何设计。换句话说，我们分别维护每个API的版本。即： POST /api/accounts/v2 GET /api/accounts/details/v3 使用这种方法，当需要中断更改时，我们可以增加特定API的API版本，而无需增加整个API的版本。 使用此样式而不是通用样式有什么弊端？

15 rest  api-design  versioning  enterprise-architecture  engineering 

问题： 解决最终用户认为是功能的错误的正确方法是什么？ 详细说明： 我猜想，如果很大一部分用户希望将其作为一项功能，应该将其“未固定”还是“固定”才能更稳定？但是，如果很少的用户期望它是一项功能，例如0.1％或1％，该错误必须得到解决。 从理论上讲，由于这是一个较小的错误修复程序，因此按语义版本控制考虑，它可以称为PATCH：xyZ但是，由于它确实破坏了向后兼容性（即使仅针对少数用户），因此应该是主要的提高：Xyz正确吗？只要有文件记载，它是否仍可以称为PATCH（因为它原本不是功能）？ 编辑：在这种特定情况下，这是其他开发人员使用的内部使用库的API中的错误。

15 versioning  bug  features  semantic-versioning 

我看到某些软件的文件名中包含版本号，而其他软件则没有。我更习惯于后一种类型，并且我认为这种类型更为流行，但是有时我在javascript库中看到前一种类型。例如，jQuery的文件名为like jquery-2.1.0.js而不是jquery.js。每当我更新这些类型的文件时，都必须在其他程序中查找加载这些文件的位置，并更改它们所引用的文件名，并手动删除这些库的旧版本。这对我来说很不方便，因此我宁愿重命名文件以排除版本号，并保持所引用的文件名不包括版本号。 我怀疑这些数字是用于某种版本控制的，但是不清楚何时以及如何使用它们。 在文件名中包含版本号的优缺点是什么？ 对于文件名中的哪些软件或语言区域使用版本号，而哪些区域/语言不使用版本号，是否存在事实上的共识？如果是这样，那有什么口粮吗？

15 version-control  versioning  files 

我们正在尝试确定一种对彼此依赖的软件组件进行版本编号的好方法。 让我们更具体一点： 软件组件A是在嵌入式设备上运行的固件，而组件B是其在普通PC（Linux / Windows计算机）上的驱动程序。他们正在使用自定义协议相互通信。由于我们的产品还面向开发人员，因此我们将提供两个组件的稳定和不稳定（实验）版本（固件是封闭源代码，而驱动程序是开放源代码）。我们最大的困难是如何处理通信协议中的API更改。 在驱动程序中实施兼容性检查时-它检查固件版本是否与驱动程序版本兼容-我们开始讨论版本编号的多种方式。 我们提出了一个解决方案，但我们也想重新发明轮子。这就是为什么我希望从程序员/软件开发人员社区获得一些反馈的原因，因为我们认为这是一个普遍的问题。 所以这是我们的解决方案： 我们计划遵循广泛使用的major.minor.patch版本编号，并对稳定/不稳定版本使用偶/奇次编号。如果我们在API中引入更改，则会增加次要编号。 此约定将导致以下示例情况： 当前稳定分支为1.2.1，不稳定分支为1.3.7。现在，针对不稳定的新补丁更改了API，这将导致新的不稳定版本号变为1.5.0。一旦不稳定分支被认为是稳定的，例如在1.5.3中，我们将其发布为1.4.0。 对于以下任何相关问题的答案，我都会感到高兴： 您可以提出解决上述问题的最佳做法吗？ 您认为我们的“习惯”约定好吗？ 您将对上述约定进行哪些更改？

15 versioning 

Hibernate在其4.0版本的hibernate版本中具有CR后缀，例如4.0.0.CR7。CR部分是什么意思？我什么时候使用这种版本编号？

15 versioning 

已关闭。这个问题需要更加集中。它当前不接受答案。 2年前关闭。 这个问题的答案是社区的努力。编辑现有答案以改善此职位。它目前不接受新的答案或互动。 在软件开发方面，Java版本之间的主要区别是什么？在哪里可以找到与编程相关的最重要变化的摘要？ 诸如http://www.oracle.com/technetwork/java/javase/releasenotes-136954.html之类的发行说明可能很难阅读。 例如，Java 1.5中有一个“针对每个”的新代码结构。

14 java  versioning 

我们是一家小型公司，拥有多个团队管理自己的git存储库。这是一个Web平台，每个团队的工件都在一天结束时部署以进行夜间测试。我们正在尝试使围绕版本控制和打包的过程正式化。 每个团队都有一个主分支，负责日常开发。每个团队的质量保证成员都希望将他们团队变更中的工件部署到测试台中，由厨师将所有组件组合在一起。工件是压缩包，但我想将其转换为RPM，以便我们可以正确思考和推理版本。 发布过程涉及从每个git存储库的开发分支（在大多数情况下为master）切断发布分支。然后将其提供给质量保证，由质量保证对一组工件进行测试和签核。 例如，这是一个典型的git存储库及其相关的发行分支： 0-0-0-0-0-0-0-0-0-0 (master) | | 0 0 (rel-1) | 0 (rel-2) 我一直在试图找出一种方案来执行来自开发分支的软件包的版本控制。我们不想过多地标记每个仓库的主分支，并限制标签仅释放分支。但是我们应该能够使用标准的yum / rpm语义查询测试机器中已部署的软件包。当master分支没有标签时，开发版本会是什么样？我知道这git describe可以为我提供构建版本的有用表示，但是当标记分支上的各个发行点时，它可以很好地工作。 编辑1：响应@ Urban48的答案 我认为我应该多解释一下发布过程。为了便于讨论，我们假设master在所有存储库中都有分支。该master分支被视为开发分支，并且已部署到支持CI-CD的自动化QA环境。这是每晚测试的子集，用于确保主服务器的稳定性。在削减发行分支之前，我们先看一下这一系列工作。我们的发行分支是短暂的。假设（从稳定的主服务器上）剪切了一个发布分支之后，将运行完全回归，进行修复并将其部署到生产中。这大约需要一周的时间。我们几乎每两周发布一次产品。 我们的功能分支总是从母版中剪切下来的，并在与母版合并之前经过一定量的开发人员测试，然后对它们进行CI-CD稳定性检查。 修补程序是在修补程序分支（从发行版分支切下的）上进行的，并以最小的影响测试将其部署到生产环境中。 以下是我们针对发行版和修补程序分支的版本控制策略。在质量检查周期中，发行分支会经历的版本v2.0.0-rc1，v2.0.0-rc2最后在质量检查批准后变为v2.0.0。 有时，我们会针对一些小功能进行点发布，这些小功能会合并到版本变为的版本分支（然后合并到母版）中v2.1.0。修补程序采用该v2.1.1模式。 但是，问题不在于对这些分支进行版本控制。我不希望完全更改此版本控制方案。唯一的变化来自开发部门。主。如何在CI-CD环境中可靠地指示在生产中的先前发行版中存在哪个版本。理想情况下，这可以通过智能git标记完成，但最好不要过度标记master分支。

13 git  continuous-integration  versioning  release-management  packages 

使用git，maven和jenkins进行以下操作的首选方式是： 我正在开发一个应用程序，我想维护它的“ dev”和“ release”分支。我希望詹金斯同时建立两者。发行工件可能具有1.5.2之类的版本，而dev-builds仅为0.0.1-SNAPSHOT。我不想有2个不同的pom.xml文件。 我查看了配置文件，但是它们似乎无法更改工件版本。我研究的一种方法可能是在测试版本中添加“限定符”。当然，我可以重命名该文件，因为关于此的真实工件信息并不重要，因为该应用程序是独立的。 这样做的首选方式是什么？还是您会怎么做？

12 git  workflows  versioning  jenkins  maven 

我正在尝试为项目找到一种方法，用户可以在其中编辑记录，并能够查看这些记录的过去版本。这是一个使用列表的简化示例架构： TABLE list ( id int auto_increment primary key, user_id int, title varchar(255) ); TABLE list_tasks ( id int auto_increment primary key, list_id int, title varchar(255), order int, is_complete tinyint ); 因此，用户可能会进来并对列表进行几次编辑（例如，添加或删除任务，重新排序任务，标记某些任务完成，重命名任务等），然后保存它们。此时，我想生成列表和任务的“版本2”，并让他们能够查看以前的版本，但是当他们访问列表时，请始终获取最新版本。 是否存在用于以这种方式在MySQL数据库中处理版本控制数据的通用方法/设计模式？

12 mysql  versioning 

这些 帖子似乎相关，但是我的大脑开始融化，试图通过：P来思考 我的雇主刚刚开始使用源代码控制，主要是因为在雇用更多开发人员之前，“存储库”是唯一的开发人员的硬盘驱动器，该开发人员主要在家中工作。所有他写的.NET代码的检入集体，并有大量的重复（读：复制粘贴）功能。现在，我们的SCM系统是光荣的备份。 我想将某些重复的代码放入共享库中。我将单独保留原始存储库，以便我们不会破坏任何内容，我们可以在需要时移动和/或重构现有代码。因此，我为新代码（包括库）设置了一个仓库。 我的问题围绕着对库进行版本控制而没有过多的时间来烦恼我们：承认我们需要一种更一致的方法，更多的开发人员都编写非常相似的代码，管理人员和其他开发人员都愿意进行重组，但可能不会如果解决方案开始影响生产效率，则下降得很好。 在我的痴迷心中，理想的解决方案是分别构建库，而每个从属项目都是针对故意选择的兼容版本构建的。这样，我们就可以准确地知道哪些客户端具有哪个库的哪个版本，可以更可靠地重现错误，维护产品和库的独立发行分支，并且在更改共享代码时不会破坏彼此的项目。 但是，这使得更新库很麻烦，尤其是对于在家工作的开发人员而言。我希望这些库能快速变化，至少在最初（最终）将这些通用位组合在一起时会如此。我完全有可能对此进行全面考虑，并且可以根据最新的库提交构建所有内容，但我至少要做好准备，以便我们决定某些组件必须独立版本化并分散式。必须在GAC中安装某些库这一事实使得版本控制特别重要。 所以我的问题是：我想念什么？我觉得我已经专注于一种解决方案，现在正在尝试寻找可以使更改更平滑的变体。您以前使用过哪些策略来解决此类问题？我意识到这个问题无处不在。我会尽力清理并澄清所有不确定性点。 尽管我很想使用Mercurial，但我们已经在集中式商用SCM（Vault）上花了钱，并且切换不是一种选择。此外，我认为这里的问题比版本控制工具的选择更深。

12 development-process  version-control  release  versioning 

我分叉了一个项目，并做了很多更改。这个fork不仅是这里的一个小功能更改，而且是那里隐藏的bug修复，它是一个相当大的更改。仅大多数核心代码是共享的。 我在v2.5.0分叉了这个项目。有一段时间我开始在v3.0上对fork进行版本控制。但是我不确定这是否是正确的方法，主要是因为当该项目达到v3.0时，事情会变得混乱。但是我不想从v1.0或v0.1重新开始，因为那意味着项目的初期，不稳定和不透明。这是不正确的，因为大多数核心代码都非常完善和稳定。 我真的不知道该怎么办，所以我在这里问：处理这种情况的标准方法是什么？大多数分叉会重新开始，提高版本号还是执行我不知道的其他事情。

12 versioning