使用 Laravel 的语义版本控制包版本控制答案

【问题标题】：Package versioning with Semantic Versioning for Laravel使用 Laravel 的语义版本控制包版本控制
【发布时间】：2018-08-08 02:47:12
【问题描述】：

我有一个 composer 包 A 和 B。A 用于非 Laravel 项目，而 B 用一些 Laravel 特定文件（配置、外观等）稍微扩展了 A。

B 应该如何要求 A？是“^1.1”还是“1.*”？由于次要版本不应该破坏任何东西，第二个可能会更好，因为我不必经常更新 B 的 composer.json。
那么，B 是否应该匹配 Laravel 框架的版本（当前为“5.6.x”）？这是好还是坏的做法？一些包会这样做，而另一些包会为不同的框架版本创建单独的分支。

【问题讨论】：

我会建议 fork 存储库并在 composer 中添加链接。
两个包都是我的，我在私人作曲家存储库中提供它们。

标签： laravel composer-php semantic-versioning

【解决方案1】：

B 应该如何要求 A？是“^1.1”还是“1.*”？由于次要版本不应该破坏任何东西，第二个可能会更好，因为我不必经常更新 B 的 composer.json。

这完全是您的政策决定。听起来你同时控制了A和B，所以你应该很容易判断A是否真的遵守Semantic Versioning与否，以及 B 承受 A 的每一个随机小碰撞的相对风险。

那么，B 是否应该匹配 Laravel 框架的版本（当前为“5.6.x”）？这是好还是坏的做法？一些包会这样做，而另一些包会为不同的框架版本创建单独的分支。

永远不会！你不负责版本控制 Laravel，你负责版本控制 B。 B 对 Laravel 的依赖在包定义中定义。您可能有机会至少提升 B 上的补丁级别，而不受其依赖项的影响。如果您需要明确 B 适用于哪个 Laravel 版本，您可以在包名称级别包含它（B-Laravel.XYZ BX.BY.BZ )、构建元数据 (B.XYZ+Laravel.XYZ) 甚至在发布/提要级别（单独的网页、REST URI）。

我的建议是你从 1.y.z 开始，然后关注current SemVer spec。

见

【讨论】：

【解决方案2】：

如果两个包都是你的并且是私有的，那么你可以将它包含在composer.json

这是一个例子。

  "repositories": [ 
    { 
        "type": "package", 
        "package": 
        { 
            "name": "adnanmayo/laralogs", 
            "version": "0.1.4", 
            "source": { 
                "url": "https://repo.url",
                "type": "git", 
                "reference": "master" 
            }
        } 

    }
],

您还必须为凭据访问创建一个 auth.json 文件。

{
"http-basic": {
    "bitbucket.org": {
        "username": "username",
        "password": "Passwrod"
    }
}

希望这会有所帮助。

【讨论】：

谢谢，但我担心你有问题。我现在想知道如何对我的包进行版本控制。例如问题 2：我的包 B 应该从版本 1.0.0 开始，还是应该始终与它所针对的 Laravel 版本匹配。
@DoeTheFourth 你可以在你的包中指定版本和依赖项
我不知道你想说什么。 Laravel 5.5 Project 需要 Package B 需要 Package A。我应该从 1.0.0 或 5.5.0 开始版本 Package B 吗？
关于问题 1：我应该在 Package B的 composer.json 中要求 Package A 带有“^1.1”还是“1.*” >?