Semver releases #35
Merged
Semver releases #35
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This looks great to me! I'll merge this and then create a |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Improving the release practice, as proposed in #31. Semantic versioning is introduced, or at least support for it, as outlined in
DEV.md. There are also other related changes.Here's what I would like to draw attention to (each in its own commit):
go.modandgo.sumfiles in the subdirectories (porting their content to the remaininggo.mod) so the repository now coincides with its single module. It is strongly discouraged to have multi-module repositories. I'm not sure why multiple modules were originally introduced, but this situation made it difficult to work with semver and Git tags, more precisely, the main module importing the other modules and having to update their versions in the maingo.modwith every new release. I've done this with care, keeping the dependencies as they were (with the below exception) and checking that the build and tests still succeed. It looks to me like it's OK to do this, as import paths will still work and we were not yet at v1.go.mod. Actually it should have been at v3 to start with, but this was not the case because/v3hadn't been appended to the import path. Now the correct versions of the indirect dependencies are used too. This change is quite safe, as we only use one function from that repo, but I tested it anyway with the example from the README.go mod tidy.latesttag and also deleted theVERSIONfile. As detailed inDEV.md, a release can be made by just adding a semver tag to the latest commit, usingmake distas before to cross-compile (which takes the version from the tag) and creating a new release in GitHub, selecting the same tag. I already tested this flow on my fork to create a new release.@aotimme, does this fit with what you had in mind? Edits are of course welcome or a different approach could be considered altogether.