Allow non-full version strings to be compared [Fixes #19] #28

wants to merge 1 commit into


None yet

3 participants

watson commented Mar 27, 2013

This means that the following now returns true:

  •'1.2.1', '1.2')
  • semver.eq('1.2.0', '1.2')
  • etc...
@watson watson Allow non-full version strings to be compared.
This means that the following now returns true:
- `'1.2.1', '1.2')`
- `semver.eq('1.2.0', '1.2')`
- etc...
@watson watson referenced this pull request Mar 27, 2013

1.2 != 1.2.0 #19



isaacs commented Mar 28, 2013

So... there's a (perhaps unintended) side effect of this, that you'd now be able to publish a module to npm with "version":"1.2" or even "1-beta" or, "1ce-upon-a-time"

I'm not really comfortable with saying that semvers are "valid" unless they're the x.y.z three-digit thing, optionally with a tag hanging off the end. That's how it's supposed to work. For gt/lt/etc it makes sense, but it shouldn't change the externally facing default of what parse() returns.

Maybe parse() could have a flag to tell it to use the more lenient regexp? (Or gt could just parse it using a more lenient regexp.) What do you think?

watson commented Mar 28, 2013

I can see the issue. That's why I originally thought of adding a boolean argument to gt/lt/etc to enable automatic zero-padding, e.g.'1.2.1', '1.2', true);

But how would you parse 1.2-beta? is that ok? Or is the "rule" that if the version is followed by any non-integer, then both major, minor and patch have to be present? You already allow the "build" number to be optional.

isaacs commented Apr 22, 2013

The padding should just be done in gt/lt/eq, all the time. Don't change the regexps.

isaacs commented Jun 15, 2013

Doesn't apply, and this PR has gone stale. Closing, feel free to reopen.

@isaacs isaacs closed this Jun 15, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment