I think we’re just saying the same thing in two different ways - there exists no standardized process to manage versioning of Go packages. Where we perhaps differ is that I see this as a (possibly) temporary state that can change, while you see it as an intrinsic property of the Go language for some reason?
The reason I think this matters is that we (as a community) seem to be countering the request of “please version your Go packages” with “but Go packages don’t have versions” … which is circular. They could have versions if we agreed on how that would work.
To some extent I think we as a community are still too young for this to be a significant enough issue. For example, I don’t really care much about package versioning while developing an application. As long as I’m actively developing it I make sure to keep the dependencies up to date and working, regardless if I’m vendoring or trusting the latest versions from the Internet.
But when I’ve abandoned the project and a year or two has passed, and someone picks up the source and tries to build it, we may have an issue. Maybe it builds perfectly because I vendored everything, but then who knows what bugs (security or otherwise) are present in the dependencies? Figuring that out is part of what the original post talks about. The other possibility is that it doesn’t build because the dependencies have changed. Which versions of those should we get to make it build? Who knows?
The rest of the software engineering world seems to think versions are generally a good idea. I don’t immediately see why Go would be the one exception to the rule.
I think this is going to be a community driven change rather than a top down one. The top leaders for Go do things the Google way. That is, they have a giant repo with everything in it. They don’t work with versions the way you’d expect. They don’t share packages the way the rest of us do. It works for them and that’s fantastic. It’s not how a majority of software developers or organizations do things.
SemVer is common. It’s widely used and useful. It’s easy for the community to start doing SemVer release versions. Tooling to help sharing and complement build processes can then take advantage of it when it’s there.
This is one of those areas that will benefit the Go community and that will fall on the Go community to do.
That’s a pretty strong statement. I agree that it is a necessity, but would argue that it isn’t the only thing that is important. I think it is also important to minimize the barriers for building and maintaining nicely scoped reusable packages.
Once you have versioned packages that get vendored into multiple applications you have need for a workflow to update the upstream packages.
Typically the need for the update is driven by work done on a specific application. Simply updating the vendored copy of the package and moving on is a road to chaos and regressions. Making a new release of the vendored package that fixes the bug or adds the needed feature is preferred, but the workflow seems cumbersome today.
I use gb for application projects with each project rooted in a separate directory and a centralized GOPATH when working on library packages. The workflow I have been using lately generally has the following steps.
Do some experimentation and testing on the vendored copy to make sure the changes work in the context driving them.
Switch my development environment out of the application project to my central GOPATH that allows me to implement and test the changes and commit them to the shared package’s main repo.
Tag and push a new release of the shared package.
Return to the application project.
Update the vendored copy of the shared package from its main repo.
The above workflow becomes a barrier that discourages building and maintaining nicely scoped reusable packages. Maybe there is a better way. If so, please share.
I don’t completely agree with this. For example, a dependency could have a security update that needs to be incorporated. Currently there is no method or discussion for something like this. Your application could have no work done but you need to roll in a dependency security update. This is just one example.
I did not intend to discount the scenario you describe, but to offer an additional use case. To clarify my scenario: I am talking about the co-evolution of a collection of applications and shared library packages that one might typically see in an enterprise setting.
