为什么不支持版本区间绑定

[Norcy]

pushy update 命令，只支持 minPackageVersion 和 maxPackageVersion 二选一，为什么不能支持同时生效。

比如热更新的 A 包，我希望是原生的 [10, 12] 生效；热更新的 B 包，我希望是原生的 [13, 14] 生效。

问这个问题的初衷是这样的，我害怕此时打的热更新包对未来的原生包产生影响，所以想强加一个限制。比如我打包的顺序是这样

原生 10 -> 热更新 A -> 原生 11

正常热更新 A 发布的时候，只有原生 10，所以只会绑定到 10 上；但是如果在原生 11 发布后，此时我不小心将热更新绑定到 11 上，会不会 11 也应用了这个热更新？？

设想另一种场景，热更新 A 的原本生效范围就是 [10, ∞)，因为 10 以下的原生包缺少 Native 依赖，所以最低要保持 10，此时没任何问题。我在 12 的原生包上加了一个新的 Native 依赖，并且 JS 代码无法兼容 12 以下了，所以后续我打的热更新 B 的生效范围就是 [12, ∞)。突然 A 有个 Bug 要修，那我此时 A 的版本范围就是 [10,12)，但是我似乎无法通过命令行实现这个，只能到管理后台手动绑定？

把 10 和 12 换成 1 和 100000000，那我岂不是要手动操作 99999999 次

[sunnylqm]

你说的有道理，这个场景有其合理性，但是明显也增加了复杂度

设想另一种场景，热更新 A 的原本生效范围就是 [10, ∞)，因为 10 以下的原生包缺少 Native 依赖，所以最低要保持 10，此时没任何问题。我在 12 的原生包上加了一个新的 Native 依赖，并且 JS 代码无法兼容 12 以下了，所以后续我打的热更新 B 的生效范围就是 [12, ∞)。突然 A 有个 Bug 要修，那我此时 A 的版本范围就是 [10,12)，但是我似乎无法通过命令行实现这个，只能到管理后台手动绑定？

这里其实更像是一个cherry pick对吧，那么既然是cherry pick，手动操作是否也更有其必要性？这个绑定区间支持起来不难，就是多出来的校验规则会很多很复杂，而且推演下去的话，是否还会有不连续区间？（排除某些特定版本？）

我们这边会再考虑下