这是一个似乎有点难以找到信息的主题。我是否需要更新/面向未来的Symfony附带的composer.json文件，因为〜近似版本偏离实际的最新版本更远和更远？
这只是留给礼仪或偏好的东西吗？我希望不会，因为作为开发人员，它很难维持标准。我想在composer.json require中看到有关读取和显示版本的方式的一些具体规则。
e.g。当我的composer.json说
时我该怎么办？"require": {
"symfony/symfony": "~2.4",
"doctrine/orm": "~2.2,>=2.2.3",
但是下载了Doctrine 7.4和Symfony 4.3？这个可以吗？或者我是否需要维护我的composer.json文件？
Composer.lock就是这样说的吗？什么是composer.lock？这是一个我不需要调整的文件，没有兴趣查看，也不想编辑。这就是我对composer.lock的结论。
与symfony兼容？像这样的条目让我有点慌，"knplabs/knp-menu-bundle": "2.0.*@dev", @dev？我很想看到它消失了。我怎么知道哪些包是哪个，也就是我如何知道我是否需要像＃34; 2.0这样的名字。* @ dev＆＃34; (which has the version, and a phase tag (dev)), or＆＃34; dev-master＆＃34;`（没有版本号，我想我最喜欢这个版本，但是你会遇到复杂的版本不匹配问题，所以这可能不是一个好的标准），那里没有标准。
（请注意，我不需要解释为什么这个包只能作为@dev使用，我知道它还没有完成的工作。这不是我的观点。）
回到保持composer.json文件本身更新，它是否真的归结为每隔几个月使用Google搜索所有这些软件包，查看软件包gist，npm和git hub repo文档，只是为了找到它难以捉摸的版本号，猜测它是为了冒你正在寻找合适的网站，最新的代码版本的风险，然后在验证它与所有其他软件包兼容后用这个号码更新你的composer.json文件？我的意思是，包装经理应该为我做什么呢？
我在版本compat信息中看到的最好的文档是这里的图表http://bootstrap.braincrafted.com/getting-started.html#requirements。如果所有当前主流的开源软件包都能采用这样的兼容性图表理念，那将是很好的，至少如果它们能够由composer.json安装，而composer.json中有一个已实现的版本检查系统。
所以我不应该定期关注composer.json以确保它包含正确的版本号吗？我的意思是，它容易被忽视，但我认为这将是致命的，而不是忽略它是我刚刚创建这篇文章的原因。维护composer.json的正确方法是什么，以及可用的资源是什么？
无论如何我无法在任何地方找到默认的composer.json文件？很高兴看到每个新的Symfony版本都有一个，所以我可以轻松地更新顶级默认Symfony至少需要X.
PHP，是的，我完全忽视了PHP，感谢你指出这一点。所以说明了兼容版本。请注意，我删除了问题的PHP部分，并将其修改为使用Doctrine和Symfony的示例。
至于声明~2.4不会在2.x上安装任何东西，我认为是你所说的，这是我希望听到的。很高兴知道这一点！
测试套件，也是我在Symfony软件包中没有使用的东西。到目前为止，我一直依赖网络驱动程序。
啊，--prefer-lowest?这验证了什么，我确实指定的版本至少相互兼容？
所以在接下来的一点上，你在下面的compat图表评论中提到了它是否属于所需部分的依赖关系，如果它不是依赖关系则不应放在required中，而只是直接将文件添加到app/resources？
你问为什么有一个默认的composer.json文件。如果我有一个人可以参考，我会知道在过去两年中慢慢走向我的配置的编辑还没有完全导致我现在遇到的破损。我只是希望看到一些坚实的基础，甚至可能还原我的文件，删除供应商和Web，以及作曲家安装/更新以查看事情是否再次开始工作，然后一次添加一个包。我现在无法做到这一点，因为我没有办法提及我的反对意义。
你是说我可以用composer init生成一个新鲜的？我完全忘了这件事。好点。
您在composer init下面提到的关于语义版本主要版本增量的另一点。我没有意识到这是一个标准的做法，当一些东西不合适时跳到下一个数字块。我不知道为什么我过去没有把它关联起来。
答案 0 :(得分：4)
你有一个中心的，非常错误的句子：
e.g。当我的composer.json说“require”时我该怎么办：{ “php”：“＆gt; = 5.3.3”， “symfony / symfony”：“~2.4”，但是下载php 7.4和symfony 4.3而不是？这个可以吗？或者我是否需要维护我的composer.json文件？
错误，Composer不会安装任何版本的PHP，但如果使用的版本与声明的版本不兼容，它会发出警告。它不会安装不会与您安装的PHP版本一起运行的软件包。
错误的是，当声明“~2.4”时，这意味着不安装3.0及更高版本，所以这不会安装symfony 4.3。
但是，是的，你需要维护你的composer.json。你应该定期检查至少两件事，可能是三件事：
composer update，然后运行您的测试套件 - 它应该可以运行。composer update --prefer-lowest，然后运行您的测试套件 - 它应该可以运行。如果发现任何不兼容性，您应该尝试排除这些版本。
我也希望看到对分支的依赖性成为过去。根据发行版的开发版本，只是稍微不那么糟糕。但只要最常见的安装指令告诉用户“需要dev-master”，这不会很快发生。对于为什么使用分支是一件坏事，社区仍然需要一些教育。
我不认为您提到的兼容性图表会增加任何有用的内容。没有可选的依赖项。如果需要，它属于“必需”部分。如果不需要，那就不依赖了。如果另一个软件包可以与这个软件包一起使用，并将它们放在一起是主应用程序的任务 - 这是应用程序开发人员要管理的任务。
为什么我无法在任何地方找到默认的composer.json文件？很高兴看到每个新的symfony发布一个，所以我可以更新顶部默认symfony需要轻松至少......
这有什么用途？默认的composer.json可能是通过运行composer init并回答问题来创建的，即添加名称，描述，许可证，开发人员联系人以及 - 可选 - 某些依赖项。语义版本控制的重点是不兼容的更新被明确标记为主要版本增量，允许您在更新时不安装它们。如果你说你可以使用Symfony 2.3版，你应该期望Symfony版本2.99也可以运行你的应用程序。
问题是功能蔓延 - 您可能会意外地使用兼容的功能，例如： Symfony 2.5，将在2.3中错过并违反您的最低版本要求。这是--prefer-lowest在您的自动化测试中的用途：您应该调查测试是否失败，如果失败是由于最低版本要求中缺少功能而更新您的版本要求 - 或修复错误使用的代码如果这是目标，那么在最低要求版本中不存在的功能。