fix: use version appropriate Go module path #307
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
📢 Thoughts on this report? Let us know!. |
|
Hey, thank you very much for this grad and descriptive PR. And maybe even in the I think this is a breaking change? Correct me if I'm wrong but if so, we could merge #255 as well before releasing a new version. |
There are two problems that cause editorconfig-checker to be difficult to use via the Go module framework: * Non-compliant module path * Non-compliant tag names The first of these problems is resolved here by adding the required `/v2` suffix to the Go module path, bringing it into compliance with the requirements of the Go module framework. Non-Compliant Module Path ------------------------- A Go module is identified by a "module path". The Go module framework requires that this path have a major version suffix if the project is at a version of 2.0.0 or above: https://go.dev/ref/mod#major-version-suffixes This project is at version 2.x, so its previous Go module path `github.com/editorconfig-checker/editorconfig-checker` violated this requirement. Non-Compliant Tag Names ----------------------- The Go module framework requires that tag names use a "v" prefix (e.g., v2.7.3). The tag name format currently used by editorconfig-checker does not have this prefix. The Go module framework does not recognize these tags as release markers. Installation via `go install` ----------------------------- The non-compliances cause the command: go install github.com/editorconfig-checker/editorconfig-checker/cmd/editorconfig-checker@latest to unexpectedly install a potentially unstable beta version of editorconfig-checker from the tip of the default branch. Once the project is brought into compliance, the equivalent command: go install github.com/editorconfig-checker/editorconfig-checker/v2/cmd/editorconfig-checker@latest will instead install the latest production release of the tool, which will be best practices for those using editorconfig-checker normally. It will still be possible for beta testers to install the development version of the tool by using @main as the ref in place of @latest. Use as Go Module Dependency --------------------------- The Go module might be specified as a dependency of other projects for either of the following reasons: * The project uses the module's packages in its own Go code * The project uses editorconfig-checker as a tool dependency and wants to manage the versioning of that dependency using a dummy "tools" Go package In either of these use cases, the project maintainer will typically have the following goals for managing the dependency: * Pin the dependency at the latest stable release version on introduction * Bump the dependency at each new stable release in a controlled manner The non-compliances make both of these difficult: By default, the Go module framework will pin the dependency at the unstable tip of the default branch if no compliant tags are found. When there isn't a compliant tag to pin to, the Go module framework, a "pseudo-version" is used for the dependency's versioning. The popular Dependabot dependency management service will not offer updates for Go module dependencies using a pseudo-version, meaning the project maintainer must manage the dependency entirely manually. Documentation ------------- The installation documentation has been updated to use the new module path. Backwards Compatibility ----------------------- Due to the lack of any compliant tags in the repository, `go get` and `go install` commands using the old module path `github.com/editorconfig-checker/editorconfig-checker` without an explicit ref will no longer work after this path change. Commands that use a commit hash ref (which includes projects that already have the dependency in their `go.mod`/`go.sum` files) will continue to work as before. Conclusion ---------- The problem of non-compliant tag names must be fixed by an adjustment to the release procedure rather than a change to the repository contents. However, the change to a compliant module path name made here lays the groundwork for bringing the project into full compliance once compliant tag names are used for future releases. Using a compliant module path as well as compliant tag names would benefit the users of editorconfig-checker by allowing them to install and manage it as a project dependency in a safe and efficient manner.
per1234
changed the title
|
You are welcome, and thanks for fixing the problem with the Makefile for me. I apologize for not having the PR in a fully ready to merge state before submission.
It is breaking for This breakage occurred at the moment the PR was merged (though it might not be immediately reproducible when using a module mirror; I had to disable it by setting the environment variable The breakage could be mitigated by creating a compliant tag for the 1.x major version series of editorconfig-checker: With that |
|
I think I've merged this as a mistake, did a lot of maintenance work in different repositories yesterday. Thank you for your detailed explanation! |
There are two problems that cause editorconfig-checker to be difficult to use via the Go module framework:
The first of these problems is resolved here by adding the required
/v2suffix to the Go module path, bringing it into compliance with the requirements of the Go module framework.Non-Compliant Module Path
A Go module is identified by a "module path". The Go module framework requires that this path have a major version suffix if the project is at a version of 2.0.0 or above:
https://go.dev/ref/mod#major-version-suffixes
This project is at version 2.x, so its previous Go module path
github.com/editorconfig-checker/editorconfig-checkerviolated this requirement.Non-Compliant Tag Names
The Go module framework requires that tag names use a "
v" prefix (e.g.,v2.7.3). The tag name format currently used by editorconfig-checker does not have this prefix (e.g.,2.7.2). The Go module framework does not recognize these tags as release markers.Installation via
go installThe non-compliances cause the command:
to unexpectedly install a potentially unstable beta version of editorconfig-checker from the tip of the default branch.
Once the project is brought into compliance, the equivalent command:
will instead install the latest production release of the tool, which will be best practices for those using editorconfig-checker normally. It will still be possible for beta testers to install the development version of the tool by using
@main, etc. as the ref in place of@latest.Use as Go Module Dependency
The Go module might be specified as a dependency of other projects for either of the following reasons:
In either of these use cases, the project maintainer will typically have the following goals for managing the dependency:
The non-compliances make both of these difficult:
By default, the Go module framework will pin the dependency at the unstable tip of the default branch if no compliant tags are found.
When there isn't a compliant tag to pin to, the Go module framework, a "pseudo-version" (e.g.,
v0.0.0-20231013082012-98f0d6560dba) is used for the dependency's versioning. The popular Dependabot dependency management service will not offer updates for Go module dependencies using a pseudo-version, meaning the project maintainer must manage the dependency entirely manually.Documentation
The installation documentation has been updated to use the new module path.
Backwards Compatibility
Due to the lack of any compliant tags in the repository,
go getandgo installcommands using the old module pathgithub.com/editorconfig-checker/editorconfig-checkerthat don't use an explicit ref in the version query will no longer work after the path change proposed here:Commands that use a commit hash ref (which includes projects that already have the dependency in their
go.mod/go.sumfiles) will continue to work as before:Conclusion
The problem of non-compliant tag names must be fixed by an adjustment to the release procedure rather than a change to the repository contents. However, the change to a compliant module path name made here lays the groundwork for bringing the project into full compliance once compliant tag names are used for future releases.
Using a compliant module path as well as compliant tag names would benefit the users of editorconfig-checker by allowing them to install and manage it as a project dependency in a safe and efficient manner.