标签: semantic-versioning

在Chart.yaml

我有kubeVersion: ">=1.10.1"

集群节点有以下版本

v1.18.0-rc.1 并且 helm 安装失败并出现错误

Error: chart requires kubeVersion: >=1.10.1 which is incompatible with Kubernetes v1.18.0-rc.1

我尝试将 kubeVersion 更改为1.10.1-rc.1但出现一些新错误

error unmarshaling JSON: while decoding JSON: json: cannot unmarshal bool into Go value of type releaseutil.SimpleHead

# helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

诚然，我对semver的理解非常有限

这

environment:
  sdk: ^2.7.0

相当于这个

environment:
  sdk: '>=2.7.0 <3.0.0'

此格式对于包发布是严格执行的

Package validation found the following error:
* ^ version constraints aren't allowed for SDK constraints since older versions of pub don't support them.
  Expand it manually instead:
  
  environment:
    sdk: ">=2.7.0 <3.0.0"
Sorry, your package is missing a requirement and can't be published yet.

latterflutter 使用in 代替该方法有什么原因吗former？

哪个可以说更熟悉和一致？

在 octopus 部署中，我想在通道上创建版本规则，以确保 nuget 包上没有后缀/标签。我已经在版本控制规则的“标签”部分尝试了正则表达式，但据我所知，标签规则仅在存在标签时才有效。例如，^[^a-zA-Z0-9]+$将仅突出显示 1.0.0.0-tag 的版本号，但如果不存在标签，则不会识别 1.0.0.0。

有没有办法使用 octopus 部署中的内置版本控制仅获取没有标签的包？

我正在使用GitLab管道，并在.gitlab-ci.yml文件中定义了我的构建定义。

我正在用它来构建docker容器。

简单的问题。有没有一种方法可以用gitlab中的semver或时间戳标记我的docker容器。

内置变量似乎并没有给我太多帮助。

在Windows上，我以前可以GitVersion在Powershell中使用它来获取semver标签并将其放入一个变量中，以便在其余的构建过程中使用。

如果无法执行此操作，是否可以从操作系统获取时间戳并将其用于yml文件？

某些情况：我正在一个团队中工作，该团队产生6个不同的NuGet程序包，这些程序包直接或有时间接地相互依赖。简单地说，我们可以像一个情况p0 < p1 < p2，其中包p0依赖p1，而这又取决于p2。我们正在尝试对这些软件包使用语义版本控制，但不确定p0在p1或p2更改时如何处理的版本。

以下是一些具体示例：

• p1进行重大更改（例如0.0.0→ 1.0.0）。我们要发布p0依赖于的版本1.0.0。这是主要版本还是次要版本p0？
• p1进行较小的更改（0.0.0→ 0.1.0）。这应该使次要版本/补丁版本生效p0吗？

更重要的是，

关于依赖版本的更改应如何影响软件包版本的更改，是否存在任何标准/共识？

我正在尝试将我的 Azure DevOps Pipeline 的内部版本号从 gitversion 设置为我的 MajorMinorPatch 版本。我的 YAML 中有以下内容用于我的管道：

- task: GitVersion@5
  inputs:
    preferBundledVersion: false
    updateAssemblyInfo: true
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      $versionInfo = '$($GITVERSION_MAJORMINORPATCH)'
      Write-Host("##vso[task.setvariable variable=Version;]$versionInfo")
- script: echo %Action%%BuildVersion%
  displayName: 'Set build version'
  env:
    Action: '##vso[build.updatebuildnumber]'
    BuildVersion: '$env:Version'

问题是当我运行我的管道时，我得到一个管道名称，如：0.1.0-alpha.70

我不知道为什么我得到 -alpha.70。我知道它们的意思，我想，但我不希望在我的版本字符串中看到它们。当我在本地运行 gitversion 时，我的 MajorMinorPatch 字符串是 0.1.0，这就是我想要看到的。谁能帮我获取这些信息？

编辑：对于任何好奇的人，我在这里包括我的 GitVersion.yml，它几乎是标准配置：

assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatchTag
mode: ContinuousDeployment
tag-prefix: '[vV]'
continuous-delivery-fallback-tag: ''
major-version-bump-message: '\+semver:\s?(breaking|major)'
minor-version-bump-message: '\+semver:\s?(feature|minor)'
patch-version-bump-message: '\+semver:\s?(fix|patch)'
no-bump-message: '\+semver:\s?(none|skip)'
legacy-semver-padding: 4
build-metadata-padding: 4
commits-since-version-source-padding: 4
commit-message-incrementing: …

在Countinous Delivery book 中，建议将所有内容（包括 CI 脚本）保留在版本控制中。实际上，像gitlab CI这样的当前 CI 系统已经遵循这个经验法则并在相同的代码库中搜索 CI 脚本。
另一方面，我们在代码库（及其构建的工件）发生变化时对其进行版本控制。我们遵循语义版本控制；为错误修正增加补丁字段，为非破坏性功能增加小，等等......
我们通过在 CI 中检查它来确保版本在提交之间增加。
但是，有些提交只会更改 CI 脚本；即添加分析作业，优化另一个等。
在这个冗长乏味的前言之后，我的问题是，对 CI 进行此类更改的版本控制的最佳实践是什么？因为它可能会影响最终构建的工件（例如，更改 CI 作业中的构建标志以进行优化或...）。
在这种情况下可以增加版本吗？

我在 Azure DevOps 中有一个构建管道，它通过发布工件npm pack供以后发布到工件提要中。

我想通过 GIT 设置我的主要和次要版本，但补丁版本与内部版本号相关联。例如

1.2.20201212.4

其中 1 和 2 是通过 GIT 手动更新的主要.次要版本，20201212.4 是由构建管道设置的补丁和修订号

有人可以帮我找出所需的npm version命令参数，以从源代码中保留次要.主要版本并仅更新 $(Build.BuildNumber) 变量中的补丁和修订部分吗？

我们正在努力做什么

我们正在使用 Azure Pipelines ( azure-pipelines.yml) 来自动化 ci/cd。我们的部分配置完成了项目的版本控制，以发布到 Azure Artifacts。我们还尝试对其进行配置以更新现有版本号，而package.json不会在 Azure DevOps 中触发新管道。

这是我们文件的相关部分azure-pipelines.yml：

  - script: |
      git config --global user.email "email@example.com"
      git config --global user.name "User name"
      npm version patch -m "Bump version to %s [skip ci]" --force
    displayName: 'Bump release version'
  - script: |
      npm pack
    displayName: 'Package package'

这可以很好地将包发布到我们的 Azure Artifacts feed，但不会更新现有版本package.json

我们的package.json包含以下内容：

"release": {
    "plugins": [
        "@semantic-release/commit-analyzer",
        "@semantic-release/release-notes-generator",
        "@semantic-release/changelog",
        [
            "@semantic-release/npm",
            {
                "npmPublish": false
            }
        ],
        [
            "@semantic-release/git", …

我对SemVer发布周期的了解如下：

1. 我的第一个版本将是0.1.0-alpha.1
2. 我可能会做一些调整，然后以0.1.0-alpha.2重新发布（根据需要重复）
3. 准备好后，我发布0.1.0-beta.1
4. 我可能会做一些调整，然后以0.1.0-alpha.2重新发布（根据需要重复）
5. 准备好后，我投入生产：1.0.0

我在整个过程中都保持相同的次要版本是否正确？SemVer网站对此进行了提示（第11节，下面的链接）：“示例：1.0.0-alpha <1.0.0”。这表明可以同时存在“ 1.0.0”的两个版本。

还是我应该为每个发行版增加次要/补丁，例如：

• 0.1.0-alpha.1

• 0.1.1-alpha.1

• 0.1.2-beta.1

• 0.2.0-beta.1

• 1.0.0

如果是这样，我不知道如何使用alpha.x或beta.x增量？

参考：https : //semver.org/