问题标签 [semantic-versioning]

PEP 0440包括以下两个似乎相互矛盾的陈述：

开发版本允许使用.、-或_分隔符，也可以同时省略分隔符。这的正常形式是使用.分隔符。这允许规范化为1.2-dev2或之类的版本。1.2dev21.2.dev2

和

请注意，devNandpostN必须始终以点开头，即使紧跟数字版本（例如1.0.dev456, 1.0.post1）使用也是如此。

第二个说法错了吗？是否允许一起省略分隔符？如果是这样，提醒 PEP 作者更正 PEP 的过程是什么？

阅读 SemVer 规范，这实际上并不是 SemVer 的一部分。那么 NuGet 实际调用的搜索语法是什么？

另外，是否有一个 .NET 类可以处理它，以便我可以使用这种语法搜索包？

我正在尝试从 SemVer 中去除前缀​​，1.2.3-prefix.42即将1.2.3.

我正在使用https://github.com/mojombo/semver/issues/32#issuecomment-7663411中的这个正则表达式：

使用 Ruby 的gsub方法时，它可以工作：

但是当使用sed终端形式时，它不会：

我错过了什么？

我在 Mac OS X 上使用 zsh。

谢谢

我有一个 npm 模块，它已经在版本下发布，并且与稳定版本4.x.x相比有重大变化。3.x.x

但是我对3.x.x版本有一些更新，并想修补它的 npm 版本。可能吗？我可以在 npm 上管理 2 个主要版本吗？

https://docs.npmjs.com/cli/publish 能解决问题吗npm publish --tag？

什么被认为是 NuGet 中的预发布包，它是不是有一个破折号后跟一些东西，例如1.0.0-something？

另外，如何使用 NuGet 使用内部版本号？有关版本控制的 NuGet 文档说您可以使用1.0.0-build123. 但是，这是否意味着任何具有内部版本号的东西都必须是预发布的？

是否可以包含内部版本号但没有预发布的 NuGet 包？

我正在提供与主 NPM 包的版本相匹配的随附包，已经采用major.minor.patch格式（例如1.3.1）。

我不想破坏主包和随附包之间的版本一致性。是否可以为匹配的随附软件包发布中间子补丁

semver 约束？类似于1.3.1.1。

即使无法匹配约束，补丁的约定是什么1.3.1以使其不重叠1.3.2？

我一直在阅读有关版本 REST API 的所有方法。在几乎所有的实现中，控制器和视图都是版本化的，但模型不是。

以 rails 为例，控制器组织为：

相应的视图也放在不同的版本目录中。为什么我们不对模型进行版本化？是因为我们希望我们的模型（底层数据库模式）不会随着 API 的发展而改变吗？当我重命名数据库中的列名并且需要一个新模型来解决这个问题时会发生什么？

有一个与语义版本有关的问题

我们有两个级别的客户 - 级别 1 和 2。我们有一个当前版本（比如 1.0.2）。我们发布了 Level 1 的版本，并进行了较小的编号更改 (1.0.3) - 但后来决定它不会进入 Level 2。现在下一个版本应该同时进入 Level 1 和 2。但是如果我们发布 1.0 .4 那么对于 2 级用户来说，它看起来就像是一个跳过。如果我们坚持使用 1.0.3，它将与我们的 1 级用户发生冲突。

那么，从 Level 2 用户的角度来看，如果我们跳过版本号，是否与语义版本严格一致？

任何链接都可以提供帮助。谢谢。

与许多语言不同，Swiftswitch必须是详尽无遗的，所以如果我有：

那么这段代码是无效的：

但是，这些是有效的：

如果我稍后添加case C到Enumeration，第一个有效代码现在将产生编译器错误。第二个是有效的，因为它使用default:, 将捕获.C。

如果我遵守 semver carthage（或 Swift 包管理器）支持，我必须为此增加主要版本吗？

对此的扩展扩展到 Objective-C（和隐式 C）。由于 Swift 中支持 C 枚举作为 Swift 枚举，因此这也适用于打算在 Swift 中使用的 Objective-C 或 C 框架。我不确定如何解决这个问题，因为这些语言没有这样的限制（如果你的编译器很好，只是一个警告）。

Here is the behavior I'm trying to achieve in AppVeyor

1. Build the code (stamp AssemblyInfo with 1.2.3.{build})
2. Test the code
3. Create the nuget package if the tests passed
4. Publish the beta package if the package created successfully (1.2.3-beta-{build})
5. Also make the package available in artifacts.

Ideally when publishing a nuget package it would be published as prerelease. In NuGet, this is done by adding alpha characters to the end of the package version. It is also considered bad practice to overwrite an existing package (indeed, many nuget implementations do not allow this).

AppVeyor does a good job of building and testing software out of github, but I don't seem to be able to control the nuget package version.

Given: A package with the next semantic version of 1.2.3 I would expect the AppVeyor {version} variable to equate to 1.2.3.{build} I would expect the nuget package version to equate to 1.2.3-beta-{build}

The first thing I tried was using variables in the {version} box. Apparently this is not allowed. AppVeyor seems to only do variable substitution for {branch} and {build} as part of the {version}. This means I'll have to maintain a separate variable for the semantic version.

The next challenge I ran into is that there's no way to set the nuget package version through the UI. It wants to default to be the same as the AppVeyor build version.

I decided to try creating the package using Powershell after the tests run. This works, but the Nuget Publish step wants to run before the package is created and there doesn't seem to be a way to control the execution order.

I think I'm on the wrong track. I need a conceptual reset.

Here is my appveyor.yml in its current (incorrect) state:

How do I fix this? Can I get the behavior I want?