Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
qmuntal opened this issue Jul 17, 2020 · 2 comments

Comments

@qmuntal
Copy link
Contributor

@qmuntal qmuntal commented Jul 17, 2020

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.

@gopherbot gopherbot added this to the Unreleased milestone Jul 17, 2020
@qmuntal qmuntal changed the title x/exp/cmd/gorelease: accept any release version when inferring unexisting base version x/exp/cmd/gorelease: accept any release version when inferring base version of untagged repo Jul 17, 2020
@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Jul 17, 2020

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
Copy link
Contributor Author

@qmuntal qmuntal commented Jul 18, 2020

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:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants