如何区分“补丁”和“升级”?你在哪里画线?
某个规范说,每当我发布产品升级时,我都需要做“X”。我需要在某处画线。我不想违反这个规范,但我以前从未真正明确地定义过它。
对于软件版本控制(尤其是语义版本控制),打补丁会升级软件的补丁版本号,更新会升级其次要版本号。对于遵循语义版本控制(MAJOR.MINOR.PATCH
格式)的应用程序,补丁定义为:
当您进行向后兼容的错误修复时,增加 [...] PATCH 版本。
在大多数情况下,补丁会更新第三个数字,即维护版本。更新更新次要版本号。此外,补丁通常可以在保持兼容性的同时修复问题,而更新既可以修复问题,也可以添加可能与以前版本不兼容的新功能。还可以在补丁号之后附加构建或修订号:
MAJOR.MINOR.PATCH or MAJOR.MINOR.PATCH.BUILD
所以版本号 2.1.3.089 是第二个主要版本,第一个次要版本(所以有一个主要更新),第三个维护版本(所以自 2.1.0.X 版本发布以来的三个补丁),以及版本 089(没有意义对于构建/补丁,可以被认为是指定唯一版本 ID/编号的附加元数据)。
关于软件版本控制的Wikipedia 文章很有趣。我指定 MMMB 样式的原因是它在应用程序开发过程中在 Visual Studio 中常用。
然而,在某些情况下,最后一个数字(内部版本)被省略了——对于最终用户来说,很少需要这样做。它主要仅用于开发目的。
补丁通常是为了修复严重错误或问题或安全问题而推出的。更新或发布可能更符合软件的附加功能和特性。
我认为没有任何“标准定义”,尽管普遍接受的定义是补丁修复错误并且升级引入了新功能。
这实际上取决于编写您的规范的人如何定义补丁与升级,而不是取决于我或其他任何人如何定义它。
对我来说,最重要的是驱动问题的原因。
补丁通常用于修复问题,因此需要用户提供。
升级通常是添加新功能,虽然有时由用户驱动,但更经常是在内部启动。
还涉及大量的营销。
我不愿意为补丁付费,而我可能会为更新付费(我在看你们 OSX 用户)。
如果规范没有定义补丁或升级,那么你可以在任何你喜欢的地方画线(并认为你可以侥幸逃脱)。假设您不想回到规范编写者那里寻求指导,我会在“错误修复”和“新功能”之间划清界限。