首页 文章

使用Laravel的语义版本控制进行包版本控制

提问于
浏览 次
1

我有一个作曲家包A和B.A用于非Laravel项目，而B略微扩展A与一些Laravel特定文件（配置，外观等） .

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

  • 那么，B应该与Laravel框架的版本匹配（目前是“5.6.x”）吗？是好事还是坏事？有些包以这种方式执行，其他包为不同的框架版本创建单独的分支 .

laravel composer-php semantic-versioning

2 回答

  • 0

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

    这完全是您的政策决定 . 这听起来像是你控制了 A 和 B ，所以你应该很容易判断 A 是否真的坚持Semantic Versioning，以及从 A 获取每一个随机轻微碰撞的相对风险 B .

    那么，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进行操作 .

    看到

    回复于
  • 0

    如果这两个包都是你的，那么你可以将它包含在 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"
    }
}

    希望这可以帮助 .

    回复于

相关问题