这是一个似乎有点难找到信息的主题。我需要更新Symfony附带的composer.json文件吗？因为近似版本与实际的最新版本越来越远了？
这只是一个礼仪或偏好的问题吗？我希望不会，因为作为一名开发人员，维护标准已经够难的了。我想在composer.jsonrequire中看到一些关于版本读取和指示方式的具体规则。
例如，当我的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的结论。
是否与symfony兼容？像这样的条目让我有点恼火，"knplabs/knp-menu-bundle": "2.0.*@dev",@dev？我很想看到它消失。我如何知道哪些包是哪个包，也就是说，我如何知道我是否需要一个像"2.0.*@dev"(which has the version, and a phase tag (dev)), or"dev-master"`这样的名称(它没有版本号，我想我最喜欢这个，但你会遇到复杂的版本不匹配问题，所以这可能根本不是一个好的标准)，那里没有标准。
(请注意，我不需要解释为什么这个包只能作为@dev提供，我意识到它还没有完成。这不是我的观点)。
回到保持composer.json文件本身的更新，它真的可以归结为必须每隔几个月在谷歌上搜索这些包中的每一个，查看包的要点、npm和git-hub repo文档，只是为了找到那个难以捉摸的版本号，猜测它以冒着你正在看正确的网站、最新代码发布的风险，然后用这个数字更新你的composer.json文件，在你验证它与所有其他包兼容之后？我的意思是，这不是包裹经理应该为我做的吗？
我看到的版本兼容信息最好的文档是这里的图表http://bootstrap.braincrafted.com/getting-started.html#requirements.如果所有当前主流的开源软件包都能采用这样的兼容性图表思想，那就太好了，至少如果它们能够由composer.json安装，而composer.jsp中确实有一个实现的版本检查系统。
所以我不应该定期关注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文件有什么用途。如果我有一个可以参考的，我会知道在过去两年里，对我的配置进行的编辑并没有完全导致我现在所经历的破坏。我只想看到一些坚实的基础，甚至可能恢复我的文件，删除供应商和网络，以及composer安装/更新，看看事情是否重新开始工作，然后一次添加一个包。我现在不能这么做，因为我没有办法将我所拥有的与有效的相比较。
你是说我可以用composer init生成一个fresh吗？我完全忘记了这件事。很好。
您在composer init下面提出的关于语义版本控制主要版本增量的另一点。我没有意识到，当compat出现问题时，跳到下一个数字块是一种标准的做法。我不知道为什么我过去没有把它联系起来。
你有一个中心的、非常错误的句子：
例如，当我的composer.json说"需要"时，我该怎么办：{"php"：">=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，然后运行您的测试套件-它应该可以工作 - 您的软件是否使用包版本的任意组合运行，例如使用composer.lock文件中记录的组合
如果您发现任何不兼容，您可能应该尝试排除这些版本。
I、 我也希望看到对分支的依赖成为过去。取决于发行版的开发版本只会稍微差一点。但只要最常见的安装指令告诉用户"需要dev-master"，这种情况就不会很快发生。社区仍然需要好好教育一下为什么使用分支机构是件坏事。
我认为你提到的兼容性图表没有增加任何有用的东西。不存在可选依赖项。如果需要，它属于"必需"部分。如果不需要，就没有依赖关系。如果另一个包可以与这个包一起使用，并且将它们放在一起是主应用程序的任务——这是应用程序开发人员要管理的任务。
为什么我在任何地方都找不到默认的composer.json文件？如果每个新的symfony版本都能看到一个，那就太好了，这样我就可以很容易地更新symfony需要的顶级默认。。。
那有什么用？默认的composer.json可能是通过运行composer init并回答问题来创建的，即添加名称、描述、许可证、开发人员联系人以及一些依赖关系(可选)。语义版本控制的全部意义在于，不兼容的更新被清楚地标记为主要版本增量，允许您在更新时不安装它们。如果您说您可以使用Symfony 2.3版，那么您应该期望Symfony 2.99版也能运行您的应用程序。
问题是功能蠕变——你可能会意外地使用兼容的功能，例如Symfony 2.5，这在2.3中会被遗漏，并违反你的最低版本要求。这就是--prefer-lowest在自动测试中的作用：您应该调查测试是否失败，如果失败是由于最低版本要求中缺少功能，则更新您的版本要求，或者修复错误使用最低版本要求不存在的功能的代码(如果这是目标)。