-
Notifications
You must be signed in to change notification settings - Fork 620
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
go modules support #388
Comments
👍 for adopting semver. Previously it was closed in #312 |
I suspect it entirely depends on what the answer to #312 is today. @streadway are you open to discussing this once again? |
I'm happy to discuss the value proposition of any change, including Go Modules or SemVer. Please make a case supported with examples. The current case I'm working with is personal preference for x.y.z labeling over date+sha labeling, so it would be easier to present and discuss the pros and cons of something other than preference with a maintenance task or regression as an example. |
@streadway thanks for the response. I think the biggest case I can make for Modules & SemVer is simply that the Go team, community, and toolchain has finally rallied around them as the solution to versioning and dependency management. For that reason alone I think it's worth adopting. To add some color to that statement:
This repo is one of the simplest cases for Modules (no external deps, no existing releases). The work required will be: add a go.mod, release Having SemVer tagged releases will also allow for any potential future breaking changes that could come. Though unlikely, it's nice to have the flexibility. Thanks for all the work on this package, and again I'm more than happy to pull the modules PR together whenever you give the 👍. |
For a library that's into its 7th year breaking changes are not also likely, they are necessary since all the inevitable mistakes in API design are now a lot more obvious than in the early days. This is even if we ignore all the changes naturally coming from the Go side. |
What I hear is that breaking changes are desired and the import-versioning recommendation suggests using a different module name instead of using tag. This effectively forks the repo using different branches for backporting bug fixes into different major versions.
I am fine with adding a go.mod which simply contains the package name to track HEAD (which is basically what we do today). We don't yet have a release process for tagged commits documented for our contributors, so the process and value of tagging commits is still unclear. Documenting the release process is a different issue. Instead of talking about tagging and go.mod (which is easy) - let's discuss what the desired breaking changes are and whether they're valuable enough to fork the releases into 2 modules. @michaelklishin could you please lead an |
WDYT about documenting the release process and v2 milestone first? |
Maybe I'm misunderstanding, but what is the need for forking this repository to work on a v2 API? If the current state of master was tagged as v1, then anyone who wanted to lock their imports to v1 can do so in their own go.mod file. v2 can be developed on its own branch and then released into master when it's ready. Also adding my general support for go modules - that's actually why I came here to see if support was being worked on :) |
This isn't a "Github fork", but rather addressability of the modules and maintaining more than one HEAD reference for each module. The recommendation is to use different module names for different major versions.
We'd keep a v1 branch that took bugfixes and v1 related improvements, and a v2 branch with a different API that would take similar bugfixes and v2 related improvements. The commits for each HEAD will continue to reside in this git repository. |
What impact would merging v2 back into master have for dependents on the v1 API that do not have a go.mod, or haven't added a |
I see. My experience of Go modules is mostly from the consumer side.
Assuming they haven't vendored, it would be a breaking change; but that's the risk they have been taking by not managing dependencies. Though I can see why that's a legitimate problem for such a widely used package as this. |
@streadway I'd be happy to do it but I need to understand the plan. I still don't fully understand why there can't be a single repo with multiple branches, that's what every other client does. API changes every few years are seen as reasonable by the vast majority of the industry (or at least its part that I interact with). This client and the protocol it implements have been remarkably stable over the years. Why not move default branch to I understand that some users would never see any announcements, would not act on it but if it's a matter of changing a branch, honestly, it's their problem. |
An alternative solution which I don't like is to fork this project as in GitHub fork, change package name, move it to the RabbitMQ org and adopt the practices used for other clients and RabbitMQ itself. Current users of this package will then continue using this plugin which will only get non-breaking fixes. I expect this to cause a lot of confusion initially and, once RabbitMQ tutorials switch to the "new client", this plugin will eventually get little attention. I don't like this on many levels, especially given that we don't plan any drastic changes to the API. |
Sorry that I hijacked this conversation but I feel we need to figure out a multi-release series strategy first and then see how Go modules would fit, even if it's the inevitable future for the Go ecosystem. |
This comment and this comment pretty much describe the version and branching workflow used in the Pika project with regard to version For this project, at some point |
We got a bit off-track. So that's formalising a potential release process using go mod, and proposing API changes that would justify a v2 release? I would be interested to hear of anyone's experiences doing regular releases of a go module. Also any examples of other repos that are doing this well. |
I don't see the need to discuss breaking changes - and thus v2 - in this context. My understanding of Can a module consume a package that has not opted in to modules? makes me think that all we need is just Once we decide to introduce v1 and therefore commit to a stable API (this is a foregone conclusion), we may want to discuss breaking changes. If we find ourselves in that position, and we have a v1 - we currently don't - we have the option of taking features on a case-by-case basis and decide at that point in time whether they merit a major version or not. With no semver, we can't even begin to have those conversations, which I perceive as frustrating for some. Did I oversimplify? |
I emphasize backwards compatibility in this library for client application simplicity (follow head, get fixes), and maintainer simplicity (develop on head, roll forward for fixes). I value client application simplicity much more than maintainer simplicity so I'm willing to adopt any release process that makes receiving updates to this library easier for application developers. It may be worthing elaborating on my opinions. I think of dependency management in 2 ways: continually integrate changes for development, or ensure build repeatability for release. We don't need SemVer for either as long as different (backwards incompatible) APIs have different names. I believe that version pinning makes receiving updates from dependencies like this library harder. Without versioning, it's one less thing to worry about. ">=1.0.0" is what this library does by default without the incidental complexity of understanding and following the version number ceremony. At work, we use go modules but we also want to accept upstream changes rapidly. To continuously integrate, we use an internal tool like https://dependabot.com/ that creates PRs to increase the version for every upstream change. I have hope that disciplined maintainers could have provided an alternative to the amount of version churn application development is faced with, just to keep up. For release repeatability, we save the built application at a test version, rather than try to save all the versions of all the dependencies. This means if we want to repeat a release, we already have the artifact and don't need to track sources. With go modules, it's documented how both the client and maintainer are expected manage v2+ changes. Following those expectations makes my opinion moot, and that makes things simpler in the long run for both future maintainers of this library and existing application developers. |
We can (and should) have these conversations without SemVer - we just would use a different import path instead of a git tag. |
An interesting read, thanks for linking! So the approach that seems to best serve all those downstream would be to add a Does that sound right? |
Yeah that sounds about right. I think we can add go.mod today without any tags. |
Based on all the conversation here I've opened #394 which simply adds the |
Would you be interested in supporting Go Modules. This would entail:
go.mod
andgo.sum
in the root of this repo.I'm more than happy to open a PR with these changes, but would like to discuss them here before doing so!
The text was updated successfully, but these errors were encountered: