Questions tagged «versioning»

当前，我们在共享存储库中为我们的PHP应用程序提供了一个主分支。我们有500多个客户是我们的软件的订户，其中大多数人针对不同的目的进行了一些自定义，每个客户都在一个单独的分支中。定制可以是不同的文本字段名称，全新功能或模块或数据库中的新表/列。 我们面临的挑战是，当我们维护这数百个定制分支并分发给客户时，我们会不时提供新功能并更新我们的主分支，并且我们希望将主分支更改推送到自定义分支以便更新他们到最新版本。 不幸的是，这通常会导致自定义代码中发生许多冲突，并且我们花费大量时间遍历每个分支来解决所有冲突。这是非常低效的，我们发现解决这些冲突时并不少见的错误。 我正在寻找一种更有效的方法来使我们的客户端发行分支与master分支保持最新，这将减少合并过程中的工作量。

140 version-control  git  github  versioning  branching 

我的组织正在考虑从SVN迁移到Git。反对搬迁的一种论据如下： 我们如何进行版本控制？ 我们有一个基于NetBeans平台的SDK发行版。由于SVN修订版是简单的数字，因此我们可以使用它们来扩展我们的插件和SDK构建的版本号。转移到Git时如何处理？ 可能的解决方案： 使用Hudson的内部版本号（问题：您必须检查Hudson才能将其与实际的Git版本相关联） 手动升级版本以保持夜间稳定（问题：学习曲线，人为错误） 如果其他人遇到了类似的问题并解决了该问题，我们将很乐意听听如何解决。

131 version-control  git  svn  builds  versioning 

不同的版本命名约定是否适合不同的项目？您使用什么，为什么？ 就我个人而言，我更喜欢以十六进制表示的内部版本号（例如11BCF），该数目应该定期增加。然后为客户提供一个简单的3位数版本号，即1.1.3。 1.2.3 (11BCF) <- Build number, should correspond with a revision in source control ^ ^ ^ | | | | | +--- Minor bugs, spelling mistakes, etc. | +----- Minor features, major bug fixes, etc. +------- Major version, UX changes, file format changes, etc.

107 project-management  development-process  naming  versioning 

我看到Java 1.2也称为Java2。“ Java 1.x”和“ Java x”（例如“ Java 1.6”和“ Java 6”）是否引用相同版本的Java？ 如果是，为什么需要这种双重性？

58 java  history  versioning  product-names 

我对内部版本号的看法是，每当创建一个新的每晚内部版本时，都会生成一个新的BUILDNUMBER并将其分配给该内部版本。因此，对于我的7.0版本应用程序，夜间版本将为7.0.1、7.0.2等。是这样吗？那么在内部版本号之后REVISION的用途是什么？还是在每个夜间构建后增加REVISION部分？我在这里有点困惑...我们是否将每个每晚的建筑都称为BUILD？ 此处提到了格式：AssemblyVersion-MSDN

55 builds  versioning 

我们有多个具有不同需求的客户。尽管我们的软件在某种程度上实现了模块化，但是几乎可以肯定，我们需要在这里和那里为每个客户调整一些模块的业务逻辑。所做的更改可能太微小了，不足以证明为每个客户端将模块拆分为一个单独的（物理）模块是合理的，我担心构建会出现问题，从而造成链接混乱。但是，这些更改太大且太多，无法通过某些配置文件中的开关进行配置，因为这会导致部署期间出现问题，并且可能会带来很多支持问题，尤其是对于修补程序类型的管理员而言。 我想让构建系统创建多个构建，每个客户端一个，其中更改包含在单个物理模块的专用版本中。所以我有一些问题： 您是否建议让构建系统创建多个构建？如何在源代码管理（尤其是svn）中存储不同的自定义项？

46 versioning  continuous-integration 

软件开发人员通常不使用日期作为版本号，尽管YYYYMMDD格式（或其变化形式）看起来足够坚固可以使用。该计划有什么问题吗？还是仅适用于有限的“类型”软件（例如内部生产）？

43 versioning 

可能重复： 您使用什么“版本命名约定”？ 您是在发布前还是发布后立即更改主要/次要/补丁版本号？ 示例：您刚刚向世界发布了1.0.0（真是！）。但是，等等，不要庆祝太多。1.1.0将在六周内发布！因此，您可以修复错误并重新构建。那叫什么建筑？1.1.0.0或1.0.0.xxxy（其中xxxy是1.0.0的内部版本号递增）？ 请记住，您可能有100个要加入1.1.0的功能和错误。所以最好将其命名为1.0.0.xxxy，因为您距离1.1.0还差得远。但另一方面，另一个开发人员可能正在开发2.0.0，在这种情况下，您的构建可能会更好地命名为1.1.0.0和他的2.0.0.0，而不是分别是1.0.0.xxxy和1.0.0.xxxz。

40 versioning 

我最近与一位同事讨论了有关Web应用程序版本控制的问题。 我认为您根本不需要它，并且，如果您只想进行健全性检查以确认您的最新版本已经发布，我认为日期（YYMMDD）可能就足够了。 我在基地外吗？我错过了重点吗？我应该使用Web应用程序版本号吗

35 web-applications  versioning 

我解释提出了构建系统（摇篮/ Artifactory的/詹金斯/厨师），以我们的高级建筑师之一，他所提出的意见，我认为我的那种不同意，但我没有足够的经验，真正权衡上。 该项目构建了一个Java库（JAR）作为工件，供其他团队重用。对于版本控制，我想使用以下语义方法： <major>.<minor>.<patch> 其中patch指示错误/紧急修复，minor指示向后兼容的发行版，并major指示API的大规模重构和/或向后不兼容的更改。 就交付而言，这就是我想要的：开发人员提交一些代码；这将触发构建到QA / TEST环境。一些测试已经运行（一些自动化，一些手动）。如果所有测试均通过，则生产版本会将JAR发布到我们的内部仓库中。至此，应该正确地对JAR进行版本控制，我的想法是使用build.numberCI工具自动生成并提供的JAR 作为补丁号。 因此，版本控制实际上是： <major>.<minor>.<build.number> 同样，build.numberCI工具在哪里提供。 架构师对此表示否认，称使用CI版本号是语义版本控制的“滥用”。 我的问题是：这是正确的吗？如果正确，为什么？如果没有，为什么不呢？

35 continuous-integration  versioning  builds  continuous-delivery  semantic-versioning 

程序员之所以喜欢SVN而不是CVS的原因之一是前者允许原子提交？这是什么意思 ？

34 svn  versioning  cvs 

我不是在学校学习编程的，也不以（专业）开发人员的身份工作，因此很多基本知识对我来说还不太清楚。这个问题试图澄清其中之一。 现在，假设我有问题#1，#2并且#3在我的“问题跟踪器”中已设置要针对版本进行更正/增强，1.0.0并且最后一个（稳定）版本是0.9.0。 我1.0.0什么时候应该增加版本？当a）仅关闭了上面列出的问题之一，或b）当与版本相关的所有问题1.0都结束了？ 哪一种是正确的方法？通过正确的方式，我指的是当前行业中使用的东西。

23 versioning  semantic-versioning 

产品版本（例如）v1.0.0.100不仅代表软件的唯一生产版本，而且还有助于识别该产品的功能集和修补程序阶段。现在，我看到两种方法来维护产品的最终程序包/内部版本/二进制版本： 版本控制。一个文件存储着版本号。持续集成（CI）构建服务器将具有脚本来构建软件，该脚本使用此签入的版本号将其应用于所需的软件的所有区域（二进制文件，安装程序包，帮助页面，文档等）。 环境和/或构建参数。这些在版本控制之外进行维护（即，它们不依赖于快照/标签/分支）。构建脚本以相同的方式分配和使用数字，但是它们只是以不同的方式获取值（将其提供给构建脚本，而不是让脚本知道相对于源树在何处获取该值）。 第一种方法的问题在于，它会使跨主线分支的合并变得复杂。如果您仍然维护同一软件的2个并行发行版，并且自上次合并以来两个主版本的版本均已更改，则将在合并两个主干之间时解决冲突。 第二种方法的问题是和解。回到1年前的发行版时，您将仅依靠标签信息来标识其发行版号。 在这两种情况下，版本号的某些方面可能在CI生成之前是未知的。例如，CI构建可能会以编程方式放入第4个组件，该组件实际上是自动构建编号（例如，分支上的第140个构建）。它也可能是VCS中的修订号。 跟上软件版本号的最佳方法是什么？是否应始终在VCS中维护“已知”部分？如果是这样，主线分支之间的冲突是否成为问题？ 现在，我们通过CI构建计划（Atlassian Bamboo）中指定和维护的参数来维护版本号。在合并到我们的master分支机构之前，我们必须小心一点，即在开始构建CI之前已正确设置了版本号。关于Gitflow工作流程，我认为，如果在源代码管理中跟踪了版本号，我们可以保证在创建release分支以准备发布时正确设置了版本号。质量检查人员将在该分支机构上执行最终的集成/烟熏/回归测试，并在签收后进行合并，master这表示发布承诺。

22 version-control  continuous-integration  versioning  release-management  continuous-delivery 

假设您有一个界面IFoo： public interface IFoo { void Bar(string s); int Quux(object o); } 在API的第2版中，您需要Glarg向该接口添加方法。在不破坏现有API用户和保持向后兼容性的情况下，该如何做？这主要是针对.NET，但也可以应用于其他框架和语言。

22 versioning  interfaces 

一般而言，对于在产品生命周期中可能有多个版本并且需要先前产品支持的长期项目，处理产品版本和代码分支的最佳方法是什么？ 从更具体的意义上说，假设适当的分布式版本控制在位（即git），并且团队的大小由小到大，并且开发人员可能同时从事多个项目。面临的主要问题是，有合同义务支持当时存在的旧版本，这意味着新开发无法修补旧代码（Microsoft Office产品可能就是其中的一个示例，您只能获得针对您拥有的功能年份）。 结果，当前的产品版本控制令人费解，因为每个主要产品都具有多个依赖项，每个依赖项都有其自己的版本，这些版本可能会在年度版本之间发生变化。同样，尽管每个产品都有其自己的存储库，但大部分工作不是在主要源主干上完成，而是在该年产品发布的分支上完成，而在发布产品时将创建一个新的分支，以便对其进行支持。反过来，这意味着获得产品的代码库并非易事，因为使用版本控制时可能会想到。

21 version-control  versioning  branching  product-management