README

此存储库已废弃，请使用 `composer bump` 代替。

为Composer编写插件，用于需要具有补丁版本的包。

composer global require kubawerlos/composer-require-better

composer rb vendor/package

所有Composer的require选项（除了prefer-lowest和prefer-stable）都可以使用。

假设我们想要为我们的项目安装包acme-corporation/adding-machine，它发布了1.0.0和1.0.1版本。通常，我们会运行

composer require acme-corporation/adding-machine

我们将安装最新版本（1.0.1），并将约束^1.0添加到composer.json中。该约束意味着所有版本从1.0.0，但低于2.0.0的版本都是允许的。

这可能在将来引起一些问题

如果我们想要安装另一个允许acme-corporation/adding-machine仅在版本1.0.0（或与acme-corporation/adding-machine版本1.0.1冲突）的包，则会导致acme-corporation/adding-machine降级到版本1.0.0 - 我们很容易错过这个降级（因为它将在控制台中的一行中） - 如果1.0.1修复了对我们至关重要的错误怎么办？
如果我们运行composer update --prefer-lowest（在开发库时相当常见的做法）我们最终会得到acme-corporation/adding-machine在版本1.0.0。
当有多个包和许多允许的版本时（例如，Symfony 3 LTS的当前版本为3.4.38，因此约束^3.4允许39个版本 - 从3.4.0到3.4.38），运行composer update命令可能需要很长时间。

因此，我们可以运行

composer rb acme-corporation/adding-machine

我们将安装最新版本 - 与require命令相同，但添加到composer.json中的约束将是^1.0.1 - 这意味着所有版本从1.0.0，但低于2.0.0的版本都是允许的。这会带来什么变化？

如果我们想要安装之前降级的acme-corporation/adding-machine的包，我们会看到错误并必须做出决定 - 这对我们来说是可接受的，还是我们不能允许它？
运行composer update --prefer-lowest对已安装的包没有任何作用，因为现在安装的版本是约束允许的最低版本。
运行composer update命令将更快 - 提到的Symfony 3 LST约束将是^3.4.38，因此它将允许单个版本，而不是39个版本。
在 composer.json 文件中，我们现在将已安装的版本作为约束条件，因此我们无需使用 composer show 或在 composer.lock 文件（如果我们甚至有它的话）中检查项目中使用了哪个版本。