Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,
Please consider supporting Go Modules, the new packaging standard that will be adopted fully in Go 1.12. Experimental support is in Go 1.11 and the new module paths are supported in Go 1.9.7+ and Go 1.10.3+ in a read-only manner for backwards compatibility with all supported versions of Go.
Because this library has no external dependencies, doesn't need to import a package within its own import path, and is already tagging its releases using semver compatible tags, not much changes in the library itself except for declaring the package name and making the major version part of the import path. This means that new projects would now import this library as "github.com/dimfeld/httptreemux/v5". Older versions without a
go.mod
file would still continue to work but would automatically be converted by the tool to use a special compatibility version.Thank you for your consideration.
EDIT: it should be noted that I just picked Go 1.9 as the language being used because running tests with 1.9 appeared to work, and that's the earliest version that has some basic support for modules backported into it. Since only things using modules will read this file (and everything else will work exactly as it always had), that seemed like a safe bet for maximum compatibility. If you only support some higher version of Go and want to use features or APIs in a higher version this can be changed easily, of course.