x/exp/cmd/gorelease: accept any release version when inferring base version of untagged repo

[qmuntal]

gorelease should always fallback to none when inferring the base version in repositories without available versions.

The current implementation only fallbacks to none when releaseVersion is x.0.0 | 0.0.1 | 0.1.0 and fails one other situations. This behavior is not a semver requirement and despite being a good practice it may be too strict for modules which are required to start the version with other minor or patch numbers for whatever business, technical or legacy reason.

[jayconrod]

It seems like it's better to require an explicit -base=none in this situation (the current behavior). If the first version of a module is, for example, v1.5.2, that implies there should be a v1.5.1. If gorelease can't find any previous version, then something is probably wrong, and an error should be reported.

Could you say more about why you wouldn't start with vX.0.0, v0.1.0, or something like that? "Business, technical, or legacy reason" is not really clear.

[qmuntal]

Could you say more about why you wouldn't start with vX.0.0, v0.1.0, or something like that? "Business, technical, or legacy reason" is not really clear.

I´m adding experimental support for gorelease in an internal CI/CD pipeline that is being used by multiple teams in my organization. To use this pipeline a repo has to follow the Semantic Version 2.0.0 spec and be in compliance with the go modules requirements. Notice that non of the previous requirements force a module to start with x.0.0 | 0.0.1 | 0.1.0, and as it is not mandatory -despite being a highly recommended good practice- the pipeline allows to define a custom initial version in case the repository has no tags.

I´m afraid I don´t have a good answer for why someone would use this parameter, I´m just a man-in-the-middle, but I guess people don´t like to start a project with a low minor version for the fear of not getting adoption due to the inmaturity connotations associated to low 0.x.0 versions or to denotate some kind of continuity when creating a new spun-off project.

I´ve done a quick manual github search looking for initial version patterns in popular libraries and most of them starts with 0.1.0 or 0.0.1 but there are also some notable exceptions:

• aws/aws-sdk-go started with v0.6.0
• hashicorp/go-retryablehttp started with v0.5.2
• protocolbuffers/protobuf-go started with v1.20.0

It seems like it's better to require an explicit -base=none in this situation (the current behavior)

It is easy for my to add some lines of code in the pipeline to check if the repo doesn´t have any tag and add an explicit -base=none, but I wonder if this restriction really makes sense and compensates the complexity it adds to the code and to its usage.

As a data point, I had to dive into the code to understand why it was failing when using v0.2.0 as first tag but working with v0.1.0, I couldn't find it in the error message nor in the documentation.

[jeanbza]

Sorry for the slow response to this.

My understanding of the bug is this:

deklerk at deklerk1 in ~/workspace/no-base on master
$ git tag
$ # there are no tags (no versions)

deklerk at deklerk1 in ~/workspace/no-base on master
$ ~/workspace/exp/cmd/gorelease/gorelease -version v1.2.3
gorelease: could not find base version: no versions found lower than v1.2.3
$ # this should have succeeded: any version is valid, since there are no prior versions

$ ~/workspace/exp/cmd/gorelease/gorelease -version v1.0.0
Inferred base version: none
v1.0.0 is a valid semantic version for this release.
$ # this succeeded, because for vx.0.0, v0.0.1, and v0.1.0, gorelease chooses "none" as base

$ ~/workspace/exp/cmd/gorelease/gorelease
Inferred base version: none
Suggested version: v0.1.0
$ # this succeeded, because when release version is not specified gorelease chooses "none" as base

---

As a data point, I had to dive into the code to understand why it was failing when using v0.2.0 as first tag but working with v0.1.0, I couldn't find it in the error message nor in the documentation.

Could you elaborate on this, @qmuntal ? Could you provide the error message you're seeing, and maybe describe what's confusing about it so that we can analyse whether some error messages can be made more explicit? (is it the "could not find base version" message above?)

[jeanbza]

After a quick chat with Jay, we're going to:

1. Allow explicitly setting -base=none.
2. Improve the error message.
3. Continue the behavior of erroring if user sets -version to a non-"starting" version (vX.0.0, v0.0.1, v0.1.0), since it's weird and we want users to explicitly set -base=none as a way of acknowledging that they're doing a weird thing.

[gopherbot]

Change https://golang.org/cl/320229 mentions this issue: cmd/gorelease: support for non-starting first version

[qmuntal]

As a data point, I had to dive into the code to understand why it was failing when using v0.2.0 as first tag but working with v0.1.0, I couldn't find it in the error message nor in the documentation.

Could you elaborate on this, @qmuntal ? Could you provide the error message you're seeing, and maybe describe what's confusing about it so that we can analyse whether some error messages can be made more explicit? (is it the "could not find base version" message above?)

@jadekler What I was seeing is the "could not find base version" error message. The change done in CL320229 will improve the situation, thanks for that.

[gopherbot]

Change https://golang.org/cl/349997 mentions this issue: cmd/go: 'go get' no longer builds or installs packages