Honest note: this was not done here. Two releases need a real two-host test environment (one 0.2.1, one 0.2.2) and this machine only has 0.1.2. What follows is verifiable fact and the available options, not a verified method.
Verifiable fact: the two lines really do run in parallel
Publish times on npm prove 0.2.1 and 0.2.2 are maintained in parallel rather than one simply replacing the other:
| Version | Published | Note |
|---|---|---|
| 0.2.2-alpha.2 | 2026-10-27 | The 0.2.2 line opens |
| 0.2.1-rc.5 | 2026-10-29 | Two days later than the row above, with a smaller number |
| 0.2.2-rc.1 | 2026-11-04 | Becomes latest |
| 0.2.1-rc.4 | 2026-10-26 | Last rc on the 0.2.1 line |
So a 'support only the newest' assumption loses a group of users here.
Three available routes
| Route | How | Cost |
|---|---|---|
| One release covers both | Write engines.dsh as >=0.2.1-rc.5 || >=0.2.2-rc.1 and branch on host capability in code | Easiest to maintain; must be measured on both |
| Split by dist-tag | One package name, two tags pointing at different versions | Users must know which tag to install; a wrong pick is not blocked |
| Two package names | e.g. plugin and plugin-legacy | Clearest; doubles the issues and docs to maintain |
An existing example
dsh-context took the first route: >=0.2.0-rc.2 || >=0.2.1-rc.2 || >=0.2.2-rc.1 — three generation entry points, one release covering them. It is the only multi-generation form seen in this measurement.
Completing this needs two host versions booted, the same plugin code, and confirmation that both load and apply. No 0.2.1 or 0.2.2 host exists here, hence 'to be tested'.