【问题标题】:How to represent build number in NPM version?如何在 NPM 版本中表示内部版本号?
【发布时间】:2015-04-30 16:25:17
【问题描述】:

我想在 package.json 中为我的项目附加一个内部版本号。我正在寻找最好的方法。

我发现如果前面有“+”,node-semver 会将字符串识别为内部版本号。例如,这将是构建“123”。

1.0.0+123

但是,NPM 版本模块也将接受这种格式,但会删除 package.json 中的内部版本号。我应该如何在 package.json 中表示内部版本号?

【问题讨论】:

    标签: node.js npm versioning


    【解决方案1】:

    + 确实是表示内部版本号的方式。但是从 npm semver 的角度来看,拥有相同版本的不同构建是没有意义的。所以去掉内部版本号是有一定意义的。

    如果您因为这些是一系列预发布而进行不同的构建,请使用- 而不是+npm version prerelease 将增加 1.0.01.0.1-0。另一个npm version prerelease 将增加到1.0.1-1

    【讨论】:

    • 好的。似乎最好去掉内部版本号。由于较大的构建优先于较低的构建,因此我不愿将其表示为“预发布”。
    • But having different builds of the same version does not make sense from an npm semver perspective 我不同意,他们已经用- 允许了它,所以“有意义”就是像他们声称的那样简单地尊重 semver。这闻起来像个虫子。现在我想我会使用无效的减号来增加版本。 ://
    • npm 团队询问有关此决定的理由:github.com/npm/cli/issues/1479
    • @tresf 虽然如果你只是说应该保留 + 附加的构建元数据,为什么他们不这样做......这是一个好问题,虽然答案可能是为了避免在确定版本优先级时产生相关的印象。对于这是否是一个好的理由,我没有任何意见。
    • 仅仅因为meta标签没有被应用到排序中,并没有使它变得无关紧要。它实际上是发布者和消费者之间的通信渠道,不应从字符串中剥离。这似乎是开发人员认为他们最了解客户的行为方式的一个案例。
    猜你喜欢
    • 1970-01-01
    • 2011-10-20
    • 2021-09-15
    • 2013-06-23
    • 1970-01-01
    • 1970-01-01
    • 2011-07-09
    • 1970-01-01
    相关资源
    最近更新 更多