blang/semver v4 is released, but go-github-selfupdate depends v3

[mpppk]

Since v4, blang/semver follows the major version strategies of Go modules, and the import path has a v4 suffix. Due to this change, the selfupdate.UpdateSelf method is incompatible with v4, because UpdateSelf expects a v3 semver.Version struct as an argument.

func UpdateSelf(current semver.Version, slug string) (*Release, error) {

The structure of Version struct has not changed between v3 and v4, so the following workaround is available.

import (
	semverv3 "github.com/blang/semver"
	"github.com/blang/semver/v4"
	"github.com/rhysd/go-github-selfupdate/selfupdate"
)

v := semver.MustParse("1.2.3")

var v3PRVersions []semverv3.PRVersion
for _, version := range v.Pre {
	v3PRVersions = append(v3PRVersions, semverv3.PRVersion(version))
}

v3v := semverv3.Version{
	Major: v.Major,
	Minor: v.Minor,
	Patch: v.Patch,
	Pre:   v3PRVersions,
	Build: v.Build,
}
latest, err := selfupdate.UpdateSelf(v3v, slug)

However, go-github-selfupdate needs changes to support v4.
I think there are two options: just accept v4 Version as an argument, or define an own Version struct so that it does not depend on the version of blang/semver. Either way, it will be breaking changes.

[rhysd]

Thanks for the report.

Which a bug or an enhancement is this? What is a problem when we keep using semver v3? As you pointed, updating semver package version will cause major version update in this package because we're using semver.Version struct as part of API of this package.

[mpppk]

This is the enhancement for users who wants to use the latest version of blang/semver.
I think that the advantages of v4 are the following two:

1. User can access to new features that may be provided to v4 in the future

Currently, there are no functional differences between v3.8.0(latest version of v3) and v4.0.0. But in the future, only bug fixes will be provided for v3.

2. v4 is a compatible go module, but v3 is not.

Since v3.6.0 blang/semver has included go.mod in its repository, Version validation for incompatible packages introduced in Go1.13 will fail the installation.
Therefore, if users use go modules with Go1.13 or later, only v3.5.1 or an older version is available. The lack of availability of the latest version of v3 is confusing to users. This issue does not exist in v4 because it is a compatible go module.

---

To support v4, providing the v2 API of go-github-selfupdate is a way to avoid breaking APIs for existing users. However, more effort will be required for future maintenance. Another way is to provide API like func UpdateSelfWithV4Version(current semver_v4.Version ... or func UpdateSelfWithVersion(current OwnVersionStruct .... These are not very beautiful API, but it's easy to maintain.

What do you think about whether go-github-selfupdate should support blang/semver v4 and how to implement it?

[rhysd]

Thank you for the detailed explanation.

Hmm, I'm actually conservative to break compatibility. If v3 works fine for go-github-selfupdate, I want to keep the version until real-world issue and/or benefit appears since it does not sound urgent. When we need major version update due to some other reason, we can also update version of semver module. Can I ask you your use case of this enhancement?