Magento 2的开发和部署包括一个正式的版本控制过程，其中核心Magento模块的主要和次要版本将根据向后兼容功能的变化而增加。
作为Magento模块开发人员，我应该如何在自己的composer.json文件中构建需求列表？每当我使用一段Magento核心代码require:...并向composer.json 添加一行时，是否需要手动查看模块？还是有一个自动化工具可以为我做到这一点？
如何指定要包含在我的版本中composer.json？它应该是我针对的特定模块版本吗？还是我应该涉及某种通配符？还是我需要根据权衡做出决定？如果是这样，每种样式指定所涉及的权衡是什么？
对此功能有很多高级描述-但是尚不清楚工作中的开发人员应在此处采取哪些实际步骤，和/或这些步骤的实际后果是什么。
Answers:
每当我使用一段Magento核心代码并在composer.json中添加require：...行时，是否需要手动查看模块？
是的，每次在代码中使用核心模块中的任何内容时，都需要将其添加到作曲家的需求中。由于您可能希望加载顺序位于核心模块之后，因此我也建议您module.xml在序列部分将其添加到文件中。
还是有一个自动化工具可以为我做到这一点？
我还没碰到 如果有请让我知道。它需要是一个相当复杂的工具，并且可能需要大量的测试范围，然后运行不同版本的矩阵以生成工作集。
如何指定要包含在composer.json中的版本？它应该是我针对的特定模块版本吗？还是我应该涉及某种通配符？还是我需要根据权衡做出决定？如果是这样，每种样式指定所涉及的权衡是什么？
定义版本号的选项
100.0.2
仅在此特定版本时有效
100.0.*
*是一个通配符，并且可以与任何版本号被替换
100.0.0，100.0.1，...，100.0.120
~100.0.2
使得2通配符只能上去所以100.0.2，100.0.3， ...，100.0.120
^100.0.2
允许任何释放直到101等等100.0.2，100.0.3，...，100.1.0，100.2.5
对于选项2-4，如果您的稳定性设置允许，它还将包含类似的版本 100.0.1-beta
实际使用
选项1.）是最谨慎的选项，您知道针对哪个版本开发并且仅接受使用该特定版本-您的模块只能与该版本的特定模块一起安装。其他所有安装/升级尝试均将失败，并显示一条作曲家消息，提示其找不到一组可安装的组件。
选项2.）我认为可以将其视为非选项，如选项3所述。 ~100.0.0
选项3.）只要不引入任何新功能，就兼容
选项4.）只要不引入重大更改，就应该兼容
权衡取舍
1您的扩展程序仅适用于1个版本的Magento模块（从技术上讲，如果模块中没有任何更改，则版本号不应增加，并且从理论上讲，多个Magento Project版本可以包含具有相同版本的相同Magento核心模块。实际上，我还没有看到，看起来好像需要在Magento端进行一些处理更改（请参见此处）。由于您与Magento核心模块的1个版本联系紧密，如果您想保持兼容，最终会得到很多扩展和自己扩展的版本。
3-4您的扩展程序可与Magento的多个版本一起使用，并且您无需在每次Magento发布新版本时都发布不同版本的扩展程序。不利的一面是，即使您可能在Magento中引入了与您自己的代码不兼容的更改，您仍声称自己具有兼容性。这种风险是真实存在的，因为Magento对自己的模块版本的语义版本控制的定义仅扩展到具有有限范围的带有@api注释（在GitHub问题中对此有更多注释）标记的内容。
tl; dr;
100.0.2安全使用它，为您维护大量版本以供
^100.0.2语义版本控制其工作方式，为您减少发行量，但由于当前@api注释类和方法的范围有限，因此风险较高。如果您使用经过认可的类和方法扩展为100％，这将是显而易见的选择。
它可以像0.1.0-alpha1 -> 0.1.0-alpha2, 0.1.0-alpha3,基于模块的稳定性一样。正如文档中所共享的，需求将类似于：
"require": {
"myexamplestore/product-bundle": "2.0.0-RC1",
"myexamplestore/acme-extension": "~1.0"
}根据您的更新，此更新应为：-
"require": {
"myexamplestore/product-bundle": "2.4.0-RC1",
"myexamplestore/acme-extension": "~2.0"
}我认为目前还没有任何自动化系统，但是根据文档，遵循这一点非常重要。
但是，如果模块中有一些小错误修复，则应使用PATCH。
参考
PATCH指示向后兼容的错误修复
您说得对，答案尚不明确，但您可以看到它的更新时间大约是1年。但这就是事实。