search

ember-cli / ember-compatibility-helpers

Helpers that allow you to write backwards compat Ember addons
MIT License
24 stars 20 forks source link

Avoid `semver.satisfies` when possible. #12

Closed rwjblue closed 6 years ago

rwjblue commented 6 years ago

tldr;

> let semver = require('semver')
 undefined
> semver.satisfies('3.5.0-beta.1', '>= 3.4.0-beta.1')
false
> semver.gte('3.5.0-beta.1', '3.4.0-beta.1')
true

From https://www.npmjs.com/package/semver#prerelease-tags:

If a version has a prerelease tag (for example, 1.2.3-alpha.3) then it will only be allowed to satisfy comparator sets if at least one comparator with the same [major, minor, patch] tuple also has a prerelease tag.

For example, the range >1.2.3-alpha.3 would be allowed to match the version 1.2.3-alpha.7, but it would not be satisfied by 3.4.5-alpha.9, even though 3.4.5-alpha.9 is technically "greater than" 1.2.3-alpha.3 according to the SemVer sort rules. The version range only accepts prerelease tags on the 1.2.3 version. The version 3.4.5 would satisfy the range, because it does not have a prerelease flag, and 3.4.5 is greater than 1.2.3-alpha.7.

The purpose for this behavior is twofold. First, prerelease versions frequently are updated very quickly, and contain many breaking changes that are (by the author's design) not yet fit for public consumption. Therefore, by default, they are excluded from range matching semantics.

Second, a user who has opted into using a prerelease version has clearly indicated the intent to use that specific set of alpha/beta/rc versions. By including a prerelease tag in the range, the user is indicating that they are aware of the risk. However, it is still not appropriate to assume that they have opted into taking a similar risk on the next set of prerelease versions.