作曲家依赖关系

Matomo需要运行各种包。这些需求是使用作曲家．

添加新需求

如果出于某种原因需要一个新的需求，我们需要使用composer来要求它。

编译器需要package/name ^1.2.3

如果所需的包仅用于开发，则应该将其排除在使用以下功能的其他环境之外:

编写器require-dev包/name ^1.2.3

更新工作流程

小规模或补丁发布更新

几乎所有的要求在我们composer.json是定义在一种方式，允许次要和/或补丁发布更新没有任何调整composer.json．由于这些更新通常没有预期的问题，所以有一个自动GitHub动作它会自动检查更新，并在有可用的情况下创建一个Pull Request。

主要更新

每6个月，我们应该检查需求可能的重大更新。只有在以下情况下才能升级:

• 有一个严重的安全修复程序可以利用该组件
• 它仍然支持相同的最小PHP版本

在其他情况下，我们通常无法升级到主要更新，需要等待下一个Matomo主要版本。这是为了保持与Matomo的向后兼容性，包括WordPress，云，以及市场上的所有第三方插件，以及更多不在市场上的插件。

没有破坏性更改通常不是升级的理由，因为通常总是会有破坏性更改，即使只是一个方法定义的更改，然后导致Matomo for WordPress的问题。

对于Matomo For WordPress来说，主要组件更新不仅会导致我们管理的代码出现问题，还会导致与使用不同版本组件的超过50,000个WordPress插件的兼容性问题。大多数WordPress插件使用这些组件的旧版本，它们有不同的类和不同的方法定义，从过去的经验来看，这将导致Matomo for WordPress突然崩溃，有时甚至是整个WordPress安装。这在WordPress的自动更新中尤其令人讨厌。我们不希望在任何可能的情况下在小版本更新中破坏某人的安装。

对较新的PHP主版本的支持可能是升级组件的一个原因。然而，如果有可能的话，我们希望避免这种情况，而是自己开发组件并应用修复，假设这样做不会花费4天以上的时间。如果工作量很大，那么我们就需要一起评估风险。

检查可能的更新

Composer允许查看已安装包的所有可用更新:

作曲家过时

更新需求

如果有可用的主要更新，我们应该浏览它们并更新每一个。由于一些更新可能需要我们这边的代码更改，所以最好只更新一个需求。否则，很难确定为什么有些代码会崩溃，或者为什么有些测试开始失败。更新单个需求可以通过以下方式实现:

• 中更新已更新组件的版本号matomo / composer.json如果需要
• 执行Composer更新——带有依赖包/名称．你需要替换包/名称需求的名字，比如phpmailer / phpmailer．
• 提交&推送composer.json而且composer.lock．
• 检查是否有任何测试失败，并根据需要调整代码/测试。
• 创建一个PR并将其合并。

注意:我们使用——依赖关系选项，以确保在需要时更新所有依赖项。

不兼容的需求问题

由于Matomo的PHP版本要求，更新某些依赖项可能无法工作。有些包像PHPUnit)可能需要比Matomo更高的PHP版本。这将导致编写器不能更新到较新的版本，或者在更新依赖项时安装编写器失败composer.json．

如果更新到新版本是强制性的，基本上有两个可能的选项*增加PHP版本要求(这通常只在主要版本中执行)*创建包的分支并降低最低要求(如果代码确实符合我们的最低PHP要求)

注意:如果您想在本地安装较新的需求以进行测试，您可以使用——ignore-platform-reqs作曲家的选择。

更新内部包

我们正在处理一些核心组件以及通过composer生成的库。每当我们发布这些包的新版本时，我们都应该直接在Matomo中发布作曲家需求的更新。

• 中更新已更新组件的版本号matomo / composer.json如果需要
• 执行作曲家更新matomo/$COMPONENT_NAME．你需要替换COMPONENT_NAME美元使用组件的名称。对于您可能需要执行的缓存组件编写器更新matomo/cache matomo/doctrine-cache-fork．
• 推composer.json而且composer.lock．
• 创建一个PR并将其合并。