请问这段逻辑的目的是什么?
https://github.com/lisong/code-push-server/blob/42f8e7672db9d8a1f84133c961c2373b03fbfb60/core/services/client-manager.js#L147
正常来说应该是收到最新的更新,但是这里为什么要加入版本区间判断呢。
如果之前推送过 7.0.0 版本的热更。按这个逻辑,后续推送的 7.0.0-7.0.2 更新客户端就收不到了。
如果推送了特定版本7.0.0,那么特定版本优先,如果希望应用用版本区间,可以试着删除特定版本
怎么删除特定的版本? @lisong
I don't think this is intuitive or practical, and I propose we change it.
When you deploy a new build via code-push, you specify which app versions are compatible and should get this update. This is based on your current knowledge of historical versions. An older deployment specified a different set of versions, based on the knowledge of compatibility at that time.
Here's a concrete example. An app is deployed to the store as v1.0.0. A minor change is required, so a code-push deployment targets "1.0.0", because that is the only app version that exists (there's no way to know whether a future version of the app should receive this deployment). Now you publish a new minor version of the app to the store as v1.1.0. Again, a small change is required, and you want those with v1.0.0 to get it too, so a code-push deployment targets "1.0.0 - 1.1.0". With the current implementation of code-push-server, the users of 1.0.0 won't receive this update.
Even if you use semantic versions, you can easily run into the same issue. Imagine the first deployment targets "~1.0.0" and the second targets "^1.0.0". Users with v1.0.0 will not receive the second update.
Having to manually delete old deployments is not a good solution.
I propose we change updateCheck to return the most recent deployment that matches the requested version. Please let me know if I should submit a Pull Request.
I propose we change updateCheck to return the most recent deployment that matches the requested version. Please let me know if I should submit a Pull Request.
@byronigoe I agree with you that the most recent deployment should be the version that the app should receive. I would be interested to see your PR 👍
For example, if server has this: v1.0.5 deployed on 10Jan22, targeting versions 1.0.0-1.0.4 v1.0.4 deployed on 8Jan22, targeting versions 1.0.0-1.0.3
When an app with version 1.0.1 looks for an update, it should be served v1.0.5