comparisons do not consider build.

[coreyfarrell]

semver.gt('1.0.0+2', '1.0.0+1') returns false, I think this should return true. Similar issues occur with other comparisons, semver.eq says these are equal.

[isaacs]

According to item 10 on the spec at https://semver.org, this behavior is required.

[coreyfarrell]

Would you accept a semver.compareBuild function returning -1, 0 or 1 so build can be easily compared without breaking the spec?

Edit: This proposed function would use semver.compare first, only perform build comparison if the semver spec says the versions are equal.

[isaacs]

That would be fine with me. I imagine that it should follow the same basic logic as prerelease tag comparisons. I'd also be ok with considering build metadata when sorting lists, but we need to continue to return `0` from `semver.compare` when versions differ only on build metadata. Basically something like this: ```js exports.sort = sort function sort (list, loose) { return list.sort(function (a, b) { return exports.compare(a, b, loose) || exports.compareBuild(a, b, loose) }) } ``` There's nothing in the spec that says they _can't_ be sorted this way, just that they must be considered equivalent in general. But I think the sorting case is undefined behavior, and we may as well have a predictable result for any given input.

…

On Wed, May 1, 2019 at 5:08 AM Corey Farrell ***@***.***> wrote: Would you accept a semver.compareBuild function returning -1, 0 or 1 so build can be easily compared without breaking the spec? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#276 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAACIR5XIFD7O73DMYW6W5DPTGB3NANCNFSM4HJLUIDQ> .

[coreyfarrell]

What do you think the correct order of 1.0.0 and 1.0.0+0 should be? I think this is a difference from the prerelease sorting logic so I would put 1.0.0 before (less than) 1.0.0+0.