【问题标题】:How to start versioning a composer package?如何开始对作曲家包进行版本控制?
【发布时间】:2014-06-14 19:59:03
【问题描述】:

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

我刚刚在 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 标签进行版本控制(?)

【问题讨论】:

  • 没有规则。现在从 0.1.0 开始,想想你想要增加它的标准。阅读流行项目如何进行版本控制并复制适合您的模型。
  • 规则基本上是版本三元组中的第三个数字在表面上不可见的任何微小变化上递增,例如修复一个错误。当您添加功能但保持向后兼容时,第二个会增加。第一个保留用于破坏/更改公共接口的大修。增加数字时,将其后面的数字归零。关键是你总是可以用 X.Y.(Z+1) 替换 X.Y.Z,通常也可以用 X.(Y+1).W,但不能用 (X+1).V.W.

标签: php git composer-php semantic-versioning


【解决方案1】:

有疑问(因为你可以选择任何你想要的策略),你可以参考semantic versioning 2.0

主要版本零 (0.y.z) 用于初始开发。任何事情都可能随时发生变化。
不应将公共 API 视为稳定的

只要您的公共 API 可以更改,请留在0.x.y

【讨论】:

猜你喜欢
  • 2017-06-28
  • 2018-04-24
  • 2015-08-27
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-11-21
  • 2017-03-22
  • 2011-10-13
相关资源
最近更新 更多