Breaking the Go major-version rule

[BatmanAoD]

Breaking the Go major-version rule

[dbanty]

@BatmanAoD there's a draft over in #867 for your review when you get a chance ☺️

[dbanty]

To be clear, you're talking about the line in go.mod, not the directory structure for multiple major versions, right? So, if Knope was at 5.6.7, the module line would be module github.com/knope-dev/knope and not module github.com/knope-dev/knope/v5.

My understanding of Go modules is basically what I've read so far to try and fix other issues in Knope 😅, so some more clarifying questions. If this module was a library, omitting the version would break consumers, right, because Go would search for the latest 1.x tag, not the latest 5.x tag? But if the module is not a library (you're versioning a binary, I assume?), then the module path doesn't matter because no one is ever looking it up?

Is the ideal path forward here an explicit config option in knope.toml for an individual package which is ignore_go_module_major_versions (but named better)? Or is there some default we can detect that wouldn't mess with monorepos?

[BatmanAoD]

Yep, I'm hoping not to have to change the go.mod line (and, consequently, all the import lines).

If it were a library, I believe that omitting the version would indeed prevent consumers from importing it the standard way (they'd have to import it by git-hash or something, IIRC). But yes, this particular project is just a binary.

I'm not sure if there's a way to do this without a config option in a way that doesn't break repos that have multiple major versions in separate folders. But the current behavior suggests that Knope does correctly determine that the version should be v5:

Getting conventional commits since last release of package
Skipping relevant tags that are not on the current branch: v5.16.4, v5.18.6, v5.16.6, v5.17.3, v5.18.5, v5.16.0, v5.16.2, v5.17.1, v5.18.3, v5.14.1, v5.18.0, v5.18.4, v5.17.0, v5.16.3, v5.15.0, v5.15.2, v5.18.7, v5.16.1, v5.16.5, v5.17.2, v5.18.8, v5.15.1, v5.18.1, v5.18.2
Finding all commits since tag v5.14.0
Looking for Git tags matching package name.
Skipping relevant tags that are not on the current branch: v5.18.5, v5.17.1, v5.18.1, v5.16.3, v5.18.8, v5.15.2, v5.18.3, v5.16.1, v5.18.6, v5.14.1, v5.18.4, v5.15.0, v5.16.2, v5.17.2, v5.17.3, v5.18.2, v5.16.5, v5.18.0, v5.16.0, v5.18.7, v5.15.1, v5.17.0, v5.16.4, v5.16.6
Finding version for go.mod
No version comment in go.mod, searching for relevant Git tags instead.
Skipping relevant tags that are not on the current branch: v5.18.8, v5.17.3, v5.18.4, v5.18.6, v5.18.3, v5.15.1, v5.18.5, v5.17.0, v5.14.1, v5.16.4, v5.16.6, v5.17.1, v5.17.2, v5.18.7, v5.18.2, v5.16.3, v5.15.0, v5.16.2, v5.15.2, v5.18.1, v5.16.5, v5.16.0, v5.18.0, v5.16.1
Found 1.6.1 from git tag v1.6.1
commit fix: set up knope in gitlab-ci and incorporate some changes based on Magneto's knope.toml
        implies rule PATCH
Using PATCH rule to bump from 5.14.0 to 5.14.1
Error:   × Problem with workflow release

Error: go::cannot_increase_major_version (link)

  × Will not bump Go modules to 2.0.0
  help: Go recommends a directory-based versioning strategy for major versions above v1. See the docs for more details.

That's with Knope v0.12.0.

[BatmanAoD]

One thing that I think would be reasonable is bypassing that "increase major version" check if there's a comment in the go.mod file. That way users could just explicitly write the version in the file themselves. I'm happy to add v5.<whatever> explicitly in the go.mod, I just don't want to do it on the import statements throughout the repository.

[BatmanAoD]

Looks like it works! Thank you!