标签: semantic-versioning

我开始开发一个我想开源并在未来项目中使用的包。我不明白开始这个的正确步骤。

我刚刚在 github 上创建了存储库，这是我的 composer.json

{
    "name": "ProgrammingAreHard/Arbiter",
    "license": "MIT",
    "type": "library",
    "description": "Convenience library to manipulate Symfony ACL's",
    "authors": [
        {
            "name": "David Adams",
            "email": "adams.david.10@gmail.com"
        }
    ],
    "autoload": {
        "psr-0": {
            "ProgrammingAreHard\\Arbiter": "src/"
        }
    },
    "require": {
        "php": ">=5.3.3"
    },
    "require-dev": {
        "symfony/security": "2.4.*",
        "phpunit/phpunit": "~4.0"
    },
    "minimum-stability": "dev",
    "target-dir": "ProgrammingAreHard/Arbiter",
    "extra": {
        "branch-alias": {
            "dev-master": "1.0.x-dev"
        }
    }
}

不过，我在版本控制方面遇到了困难。我没有制作任何 git 标签。我穿上它branch-alias只是因为我听说这是一个很好的做法。我不确定1.0.x-dev现在应该有什么。

这个时候我该怎么办？我对 1.0 版本并不满意。我应该立即在诸如“v0.1.0”之类的地方创建一个轻量级或带注释的 git 标签，还是等到我处于完全可用的状态？

我应该怎么做才能以后不头痛？

我假设作曲家使用 git 标签进行版本控制（？）

今天我在 Android Studio 中发现了这个“实验性”屏幕。

一些更新说“Gradle 提升了库版本来自……”这意味着什么？

（我检查了源代码，发现这个：https : //github.com/JetBrains/android/blob/master/android/src/com/android/tools/idea/gradle/structure/daemon/analysis/PsModuleAnalyzer.java# L59，但评论中的链接并不是很有用）

这不是一个编码问题，而是一个过程问题。

我正在构建的软件可能需要针对某些市场或一般市场进行发布后修复或添加功能。

遵循SemVer 2.0（http://semver.org/spec/v2.0.0-rc.2.html）将-标签附加到指定版本号进行标记的方案我想将标签添加+到版本号进行标记这样的发布后版本。

只要不发生重大更改，就会产生以下版本树：

1.0.1-rc1                               // initial pre-release
|
1.0.1-rc2                               // second pre-release
|
1.0.1                                   // actual release
|
|-------- 1.0.1+1 --- 1.0.1+2           // post release path
|
|
|
1.0.2                                   //non breaking
|
2.1.0                                   //1st breaking

有没有更好的方法来完全兼容 semver？

npm、jspm 和yarn 将如何处理这样的 semVer 扩展？

我是不是少了一块？有“官方”解决方案吗？

我正在使用 GitLab 为我的 dotnet 核心应用程序和 netstandard 2.0 包配置语义版本控制。

在阅读了相当多的意见后，其中一些意见相互矛盾，这对我来说很清楚。语义版本应该类似于 M.m.P.B-abc123where

• M 是主要版本
• m 是次要版本
• P 是补丁版本
• B 是构建版本（可选）
• -abc123是后缀（可选）以防我使用预发行版。它必须以字母开头

因此，以下软件包版本将是有效的：

• 1.0.0
• 1.0.1.20190301123
• 1.0.1.20190301123-beta
• 1.0.1-rc1

我的版本控制有以下 gitlab 脚本

#Stages
stages:
  - ci
  - pack

#Global variables
variables:
  GITLAB_RUNNER_DOTNET_CORE: mcr.microsoft.com/dotnet/core/sdk:2.2
  NUGET_REPOSITORY: $NEXUS_NUGET_REPOSITORY
  NUGET_API_KEY: $NEXUS_API_KEY
  NUGET_FOLDER_NAME: nupkgs

#Docker image
image: $GITLAB_RUNNER_DOTNET_CORE

#Jobs
ci:
  stage: ci
  script:
    - dotnet restore --no-cache --force
    - dotnet build --configuration Release
    - dotnet vstest *Tests/bin/Release/**/*Tests.dll

pack-beta-nuget:
  stage: pack
  script:
    - export VERSION_SUFFIX=beta$CI_PIPELINE_ID
    - dotnet pack *.sln …

我正在尝试设置GitVersion来处理我们项目的语义版本控制 (GitFlow)，但它并没有像我预期的那样自动递增。我也在努力阅读项目的文档，这不是最容易理解的。

基本上我们希望建立一个具有 Major.Minor.Patch 约定的版本控制系统，我们手动增加 Major，当一个 release 分支合并到 master 时自动增加 Minor，当一个 feature 分支合并到 develop 时自动增加 P​​atch。

这是我的当前 GitVersion.yml

mode: ContinuousDeployment
branches:
  feature:
    increment: Patch
    regex: feature?[/-]
  release:
    increment: Minor
    regex: release?[/-]
  develop:
    regex: develop$
  master:
    regex: master$
ignore:
  sha: []

同样为了测试它，我写了一个小的 ruby​​ 脚本来加速这个乏味的过程。我包含它只是为了确保我以预期的方式使用 GitVersion 和 GitFlow。

require "git"

def new_feature_branch i
  g = Git.open(Dir.pwd)

  branch_name = "feature/number-#{i}"
  g.checkout("develop")
  g.branch(branch_name).checkout

  open('README.md', 'a') do |f|
    f.puts "\r#{i}"
  end

  g.add("README.md")
  g.commit("##{i}")

  g.branch("develop").checkout
  g.merge(branch_name)
  g.branch(branch_name).delete

  print(`gitversion`)
end


new_feature_branch(ARGV[0])

输出 gitversion

{
  "Major":1, …

在运行时lerna version或lerna publish它会碰撞纱线工作区中所有包的版本并更新相关devDependencies但保持未更改的版本，peerDependencies因此包引用旧的和不正确的版本并破坏功能。

例子：

包A, B& Cwhere B&C取决于A. 都有版本0.0.1。根据对纱线工作区的建议，依赖项指向确切的版本，例如：

  "peerDependencies": {
    "A": "0.0.1"
  },
  "devDependencies": {
    "A": "0.0.1"
  },

更改A，修改B以反映 中的更改A。

现在，如果我们运行，lerna publish 我们将获得所有 3 个带有版本的包，0.0.2但B并C继续引用A@0.0.1. 这破坏了Bas 修改的功能B取决于A仅存在于 中的更改0.0.2。所以package.jsonofB开始看起来像：

  "peerDependencies": {
    "A": "0.0.1"
  }, …

我在 azure 中有一个存储库，它有默认分支“main”。

另外，我在 yml 文件中有一项用于语义版本控制的任务。

- task: gittools.gitversion.gitversion-task.GitVersion@5
  displayName: Get Semantic Git Version 

我遇到了以下错误

找不到分支个人/release1 的分支配置，回退到默认配置 System.InvalidOperationException：无法找到“开发”或“主”分支，无论是本地还是远程。

所以，我刚刚创建了一个开发分支并触发了构建，然后语义版本就成功了。

我们不想按照指导方针维护开发或主分支。

在不维护master和develop分支的情况下如何克服错误呢？

谢谢

纳雷什·埃德

我的 C 库，在 1.0.0 版本中，定义了一个结构体和一些用于分配和使用结构体的函数：

typedef struct { int x; int y; } MyStruct;
MyStruct *allocate( int, int );
void destroy( MyStruct* );
void print( MyStruct* );

用户不应该自己分配结构，也不应该按值复制它。这是与语义版本控制问题的主要区别：次要还是主要变化？. 例如，程序应该像这样使用它：

void f(){
  MyStruct *ms = allocate(0,0);
  ms->x += 1;
  print(ms);
  destroy(ms);
}

现在我需要向结构中添加一个新字段，而函数的签名不会改变。

typedef struct { int x; int y; int z; } MyStruct;

新结构比旧结构占用更多内存：如果程序尝试MyStruct直接分配实例或按值复制它，如果它链接到与构建时使用的库版本不同的库版本，则它可能会中断。

然而，这不是程序使用的方式MyStruct：只要它们遵循文档，一切正常。但是代码中没有任何内容可以阻止他们滥用结构。

我正在使用语义版本控制来对我的库进行版本控制。在上述情况下，我应该增加次要版本（以向后兼容的方式添加的功能）还是主要版本（不兼容的 API 更改）？

我正在使用 Next.js 开发一个电子商务网站，并希望将其部署到 Vercel。我已经看到 Vercel 使用 Deploy-Preview-Ship 模型 (DPS)，虽然我不确定这是否违反，但我想知道是否有办法将 GitHub 操作/标签链接到我的 Vercel 部署，所以我可以部署每个 GitHub 版本，而不是每次合并到主分支。这样我就可以保持更好的语义版本控制，并且可以将 PR 和更改批量批量发布到版本中。有什么想法或者我最好在每次合并到主程序时部署到生产环境吗？

试图向朋友解释语义版本控制的重要性,我遇到了以下两难困境.

假设我们有库libfoo,这个版本1.2.3公开了以下功能:

def foo(x, y):
    """
    Compute the sum of the operands.
    :param x: The first argument.
    :param y: The second argument.
    :returns: The sum of `x` and `y`.
    """
    return x + y

现在假设此函数及其文档更改为:

def foo(a, b):
    """
    Compute the sum of the operands.
    :param a: The first argument.
    :param b: The second argument.
    :returns: The sum of `a` and `b`.
    """
    return a + b

我的第一印象是说下一个版本将是1.2.4,因为公共界面没有改变.例如,有人调用这样的函数根本不会注意到这个变化:

foo(3, 4)

但是进一步思考,这可能是一个API中断,因为Python允许用户名来指定参数.如果有人打电话给我的功能:

foo(y=4, …