https://github.com/golang/go/wiki/Modules#gomod

This PR is just a result of the following commands (in clean Go 1.11.5 environment):

go mod init
go get ./...
go mod tidy

The aim is to prevent semver from being marked as "incompatible" in go-mod-aware modules which depend on semver. This happens just because semver is >1.0.0 (currently v3.5.1) but isn't go-mod-aware. See https://forum.golangbridge.org/t/go-get-marking-go-mod-incompatible/10686 for more.

... by making it understand that a space after a range token ('>', '<', '=') can be threated like a typo instead of like an error. Example '<= '.

Also, remove all whitespaces instead of just leading/ending spaces, as there might be spaces between a range token and a version number. Example: '>= 2.5.2'

Implemented methods:

• Version.Scan -> database/sql.Scanner
• Version.Value -> database/sql/driver.Valuer

Current implementation stores Version as a single string Field, which is most convenient when it is used as a struct field.

Thx for this awesome package. Keep up the good work!

I don't see a reason why pre-releases should not be incremented. It is very common to release early without a stable api.

We should support incrementing 0.1.0 releases and the like. #59

I notice that lots of methods in your API (e.g., Validate, Compare) take pointer arguments. But I don't see why they should. None of these operations actually mutate the object. So it should be fine to simply pass a value.

The reason I see this as an issue is twofold. First, it gives the impression (when looking at the API), that these things mutate the objects. But more important for me, it means I need to have pointers available in my code which keeps the door open for inadvertent mutation in my code as well.

Is there a reason to use the pointers in the API like you have?

v3.5.1 is the last tagged version that doesn’t include a go.mod file The newer has a go.mod file but is invalid since the module needs to have a /v3 suffix then

see https://github.com/golang/go/issues/31944#issuecomment-528272174 for more

What is the motivation behind stopping pre-releases from being incremented? I read the SemVer spec and couldn't find this rule, could you point out where you've seen this constraint?

// IncrementMinor increments the minor version
func (v *Version) IncrementMinor() error {
        //-----
	if v.Major == 0 { // why?
		return fmt.Errorf("Minor version can not be incremented for %q", v.String())
	}
        //-----
	v.Minor += 1
	v.Patch = 0
	return nil
}

Would you mind me submitting a PR to remove it?

This implements #24

The code will expand wildcards inside versions following these rules:

* when dealing with patch wildcards:
>= 1.2.x    will become    >= 1.2.0
<= 1.2.x    will become    <  1.3.0
>  1.2.x    will become    >= 1.3.0
<  1.2.x    will become    <  1.2.0
!= 1.2.x    will become    <  1.2.0 >= 1.3.0
* when dealing with minor wildcards:
>= 1.x      will become    >= 1.0.0
<= 1.x      will become    <  2.0.0
>  1.x      will become    >= 2.0.0
<  1.0      will become    <  1.0.0
!= 1.x      will become    <  1.0.0 >= 2.0.0
* when dealing with wildcards without version operator:
1.2.x       will become    >= 1.2.0 < 1.3.0
1.x         will become    >= 1.0.0 < 2.0.0

See https://github.com/blang/semver/issues/16 and https://github.com/blang/semver/pull/19 for context

I've extended the UnmarshalJSON to fall back to ParseTolerant if there is an error on Parse. If that errors too then the error is returned.

I added test cases for this that are all passing well.

This allows me to build a struct like this and have it parse automatically:

type Fields struct {
	AppVersion semver.Version `json:"app_version"`
	OSVersion  semver.Version `json:"os_version"`
	Foobar     string         `json:"foobar"`
}

This now works with my mobile clients, which version like 4.5 rather than 4.5.0 which there's no way for me to fix historically.

Fully tested (Coverage >99%)

But it seems coverage is around 87% according to batch in readme.

Please, don't get me wrong, it's just to increase awareness and we can make it great again. If you wish, I can even give a hand.

Obviously, we should make room for (at least) three digits and two dots. I considered padding a little bit more (maybe six digits is common?) but decided against it after some snooping*.

Before:

BenchmarkStringSimple   10000000               195 ns/op              16 B/op          1 allocs/op
BenchmarkStringLarger    5000000               326 ns/op              40 B/op          2 allocs/op
BenchmarkStringComplex   5000000               506 ns/op              88 B/op          3 allocs/op
BenchmarkStringAverage   5000000               411 ns/op              56 B/op          2 allocs/op

After:

BenchmarkStringSimple   20000000               117 ns/op               5 B/op          0 allocs/op
BenchmarkStringLarger   10000000               243 ns/op              32 B/op          2 allocs/op
BenchmarkStringComplex   5000000               446 ns/op              80 B/op          3 allocs/op
BenchmarkStringAverage   5000000               336 ns/op              47 B/op          2 allocs/op

* 81% of the released versions on RubyGems are single digits, and more than 99% fit after one grow.

abort "Requires Ruby 2.x" unless RUBY_VERSION.start_with? '2.'

require 'rubygems/name_tuple'
require 'rubygems/remote_fetcher'

Gem::Source.new('https://rubygems.org').load_specs(:released).each do |tuple|
  puts tuple.version.to_s
end

ruby rubygems.rb | awk -e '{ print length() }' | sort -n | uniq -c

Closes #75

This pull request slightly alters expandWildcardVersions to use strings.Contains(.x) instead of strings.Contains(x) for trying to assess whether a range condition has a wildcard. This allows prereleases with x in the name as opposed to failing with the error documented in #75: Could not get version from string: "<".

Given the version 0.1.0-x, ParseRange returns the following error:

Could not get version from string: "<"

Replacing the x with another character fixes the problem (e.g. 0.1.0-y).

This appears to be related to x being used to denote wildcards as implemented in #27: https://github.com/blang/semver/blob/4487282d78122a245e413d7515e7c516b70c33fd/v4/range.go#L330

This can be reproduced with the following test:

func TestExpandWildcardVersion(t *testing.T) {
	tests := []struct {
		i [][]string
		o [][]string
	}{
		{[][]string{{"foox"}}, nil},

                // FAILING TEST
		{[][]string{{"0.1.0-x"}}, [][]string{{"0.1.0-x"}}},


		{[][]string{{">=1.2.x"}}, [][]string{{">=1.2.0"}}},
		{[][]string{{"<=1.2.x"}}, [][]string{{"<1.3.0"}}},
		{[][]string{{">1.2.x"}}, [][]string{{">=1.3.0"}}},
		{[][]string{{"<1.2.x"}}, [][]string{{"<1.2.0"}}},
		{[][]string{{"!=1.2.x"}}, [][]string{{"<1.2.0", ">=1.3.0"}}},
		{[][]string{{">=1.x"}}, [][]string{{">=1.0.0"}}},
		{[][]string{{"<=1.x"}}, [][]string{{"<2.0.0"}}},
		{[][]string{{">1.x"}}, [][]string{{">=2.0.0"}}},
		{[][]string{{"<1.x"}}, [][]string{{"<1.0.0"}}},
		{[][]string{{"!=1.x"}}, [][]string{{"<1.0.0", ">=2.0.0"}}},
		{[][]string{{"1.2.x"}}, [][]string{{">=1.2.0", "<1.3.0"}}},
		{[][]string{{"1.x"}}, [][]string{{">=1.0.0", "<2.0.0"}}},

	}

	for _, tc := range tests {
		o, _ := expandWildcardVersion(tc.i)
		if !reflect.DeepEqual(tc.o, o) {
			t.Errorf("Invalid for case %q: Expected %q, got: %q", tc.i, tc.o, o)
		}
	}
}

Result of this test is: Invalid for case [["0.1.0-x"]]: Expected [["0.1.0-x"]], got: [[">=0.1.0-x" "<"]]

At the very least, it would be helpful to call out this corner case in the docs if fixing this would be challenging due to breaking changes.

I'm trying to implement a range check that allows any major or minor version change, but never a major change. So that anything starting with 1 but never anything starting with 2 or above.

I tried expressing that as >= 1.x, >= 1.x < 2.x, >= 1.x < 2.x.x, and >= 1.x < 2.0.0, but found that it will allow 2.x prereleases, e.g. 2.0.0-v2-5.

package main

import (
	"fmt"
	"github.com/blang/semver/v4"
)

func main() {
	v, _ := semver.Parse("2.0.0-v2-5")
	r, _ := semver.ParseRange(">= 1.x")
	fmt.Println(r(v))
	r, _ = semver.ParseRange(">= 1.x < 2.x")
	fmt.Println(r(v))
	r, _ = semver.ParseRange(">= 1.x < 2.x.x")
	fmt.Println(r(v))
	r, _ = semver.ParseRange(">= 1.x < 2.0.0")
	fmt.Println(r(v))
}

This prints true four times. I know that 2.0.0-v2-5 is "less than" 2.0.0 because it is a prerelease, but this seems to be making it caught by 1.x as well.

Using semver v4

	e, err := semver.ParseTolerant("1.15-alpine3.14")
	if err != nil {
		fmt.Println(err)
	}

returns error Invalid character(s) found in minor number "15-alpine3"

Main differences between Range:

• compiled version checker can be reverted back to string, if necessary
• possibly, you can add support of inner comparison (in rounded brackets -> (), like in mathematical operations), as well as additional comparators, or range syntax (got a few ideas from this article)

My main goal was to revert back parsed range, so possibly we can optimize it a bit without loosing backward compatibility.