Weird. <a href="https:&#x2F;&#x2F;docs.npmjs.com&#x2F;misc&#x2F;semver#prerelease-tags" rel="nofollow">https:&#x2F;&#x2F;docs.npmjs.com&#x2F;misc&#x2F;semver#prerelease-tags</a><p>I guess the argument is that, if you&#x27;re going to use &quot;&gt;=6.0.0&quot; to <i>choose</i> a version of node.js, and your options are 6.1.0 and 7.0.0-rc1, you don&#x27;t want a random release candidate. But if you&#x27;re going to use it to <i>verify</i> an existing version of node.js, a 7.0.0-rc1 that someone else chose should be considered acceptable. Their semver rules can&#x27;t distinguish these two cases.<p>PEP 440 seems to handle this by decoupling the prerelease rules and the version-comparison rules: <a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0440&#x2F;#handling-of-pre-releases" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0440&#x2F;#handling-of-pre-re...</a> &quot;Pre-releases of any kind, including developmental releases, are implicitly excluded from all version specifiers, unless they are already present on the system, explicitly requested by the user, or if the only available version that satisfies the version specifier is a pre-release.&quot;