bazelbuild
released versions on proxy.golang.org`
I noticed the tool has been released as v5.1.0 https://github.com/bazelbuild/buildtools/releases/tag/5.1.0 but v0.0.0-xxx is the latest release on https://pkg.go.dev/github.com/bazelbuild/[email protected]. Are you planning to release the versioned releases here and so they appear at eg. https://proxy.golang.org/github.com/bazelbuild/buildtools/@v/v5.1.0.info?
Still noticing this: https://pkg.go.dev/github.com/bazelbuild/buildtools?tab=versions
This may be due to the missing v prefix from the tags.
It would be great to adjust this to make it easier to update:
go install github.com/bazelbuild/[email protected]
This is helpful when we build binaries from source locally for security/environment reasons.
Any updates here? The latest version is currently still marked as "v0.0.0-20230413151140-7044e4b0e521", in https://pkg.go.dev/github.com/bazelbuild/buildtools?tab=versions
How do these versions get released on proxy.golang.org? I only push releases here on Github and to NPM.
@vladmos They are picked up automatically as new tags are added and requested by users. That is also why the format of the tag (v1.2.3 instead of 1.2.3) is important.
I've just released a new technical version tagged v6.1.2. Should it eventually appear on proxy.golang.org or does anything need to be done manually?
@vladmos It should, but I missed an important point: Go modules tend to not increase their major semver version that often and when they do, their import path needs to be modified as well (in this case, to include the /v6 suffix). The "version with Bazel" approach unfortunately appears to be at odds with Go's module versioning scheme.
Assuming backwards compatibility is ensures, would it be possible to move the Bazel version into the minor version?
@fmeum should we use the "incompatible" tag since the major version is >2?
https://github.com/golang/go/wiki/Modules#can-a-module-consume-a-v2-package-that-has-not-opted-into-modules-what-does-incompatible-mean
@tyler-french I have never used it myself, how would this look like?
I just noticed that Bazel CI doesn't seem to be prepared to handle the semantic versioning format: https://buildkite.com/bazel/stardoc/builds/866#0187c31b-4c54-45ac-9ea2-3513e38731ec
@vladmos Switching to Go-compatible tags doesn't seem to be possible. It's probably best to delete the v6.1.2 release and/or release 6.1.3 (without the v) to restore Bazel CI. Now that we know how troublesome changing the scheme is, we could address these issues one by one before attempting to use semantic versions again. Sorry for the confusion, I underestimated how difficult this switch would be.
I fixed it on the CI side, it should work again (with both versions with v and without).
Now, is there a way to make it work with go modules without changing the import path? For buildtools the version just matches the current Bazel's version (to make it easier to keep both tools in sync), changing the import path can bring more problems than solve.
I checked the docs and I think that this would only be possible for non-module projects via +incompatible, but we certainly want to keep the go.mod for buildtools.
Which essentially only leaves one alternative: Adopt a versioning scheme where Bazel version X.Y.Z corresponds to buildtools version v1.X.Y. @vladmos Do you think that could work?
rules_go is working on consolidating Go depencies that are also Bzlmod dependencies (see https://github.com/bazelbuild/bazel-gazelle/pull/1526) and consistent version identifiers between the two worlds would be very helpful.
It makes sense to change versioning to v1.x.y, I just wonder if anything needs to be done to the old versions that have the outdated versioning scheme. Should I just remove them from Github releases and/or tags?
It makes sense to change versioning to v1.x.y, I just wonder if anything needs to be done to the old versions that have the outdated versioning scheme. Should I just remove them from Github releases and/or tags?
If you delete the Github releases and/or tags, does it also delete the archives?
I think it would be OK to keep them both for now, and then communicate to consumers that they should be using the v1.X.Y.
We would probably also want to make sure Bazel/Bzlmod consumers and the BCR have a safe way to "redact" or block certain versions.
After this transition period, then it's probably safe to remove/delete the old tags (although the archives should probably stay preserved).
Thoughts @fmeum?
@fmeum @vladmos @linzhp I would like to revisit this, as I see its referenced in in https://github.com/bazelbuild/buildtools/issues/1237 and https://github.com/bazelbuild/buildtools/issues/967
My recommendation is just to prepend a v0. to the existing versions to release tags to Go. Benefits here:
v0comes with the understanding of breaking changes in minor versions (https://semver.org/)- Compatibility with
go mod tidyand in general versions on https://pkg.go.dev/github.com/bazelbuild/buildtools/build?tab=versions - Can exactly correspond to existing versions in Bazel (Go v0.6.2 -> 6.2)
@tyler-french I don't have experience with retroactive editing of already released versions, do you know if it can break anything? Also I could just remove old versions, they don't have much value anyway.
Another question is that the same versions are being released with npm (i.e. https://www.npmjs.com/package/@bazel/buildifier and https://www.npmjs.com/package/@bazel/buildozer), should those versions also get the "0." prefix? Can they be edited too?
@vladmos You don't need to edit existing versions. Since they lack the v prefix, they are being ignored by any kind of Go tooling anyway. New versions would need to follow the v0.6.2 pattern though. If you want to signal a desire to preserve backwards compatibility, you could also make it v1.6.2.
Should I at least edit the few versions that do have the v prefix, starting from v6.1.2? Do I need to make any changes to the code structure to support that (e.g. move the code into a v0/ directory)?
For the NPM packages I guess I'll need to either rename or delete old versions anyway, the v-prefix is stripped there and there's no way to understand that e.g. 0.7.2 is greater than 7.1.0.
I think as long as we keep the old archives and tags available, and also communicate this change, it should be fine.
@vladmos Those versions are also ignored as they violate the path structure: any vX.Y.Z with X>=2 needs to be in a vX directory. So you don't need to edit those either. You also don't need to change the directory layout when using X=0 or X=1.
But if I just install a package using npm install it'll fetch the largest version not knowing that starting from e.g. 7.3 the versions are now all 0.x.x. And even if I remove the old versions, if the already installed on a machine is 7.1.0, npm won't update it with 0.7.2.
What if I use v0.x.y tags on Github, but the versions reported by binaries with --version (not so important) and the versions on npm will have the v.0. prefix stripped, so they'll basically continue following the existing pattern? Will that be working or am I missing something?
Also, is it allowed to have a 4-numbers version? E.g. if the current Bazel release is 7.1.x and I want to make multiple buildtools releases, they'll be called v0.7.1.0, v0.7.1.1, etc.
Yes, NPM is (presumably) different. I was just referring to the Go versions. You could continue publishing 7.2.0 versions for NPM and 0.7.2 versions for Go. Both don't allow four version segments as far as I know.
What if I use v0.x.y tags on Github, but the versions reported by binaries with --version (not so important) and the versions on npm will have the v.0. prefix stripped, so they'll basically continue following the existing pattern? Will that be working or am I missing something?
I think that would be fine, although perhaps a bit confusing for users.
Also, is it allowed to have a 4-numbers version? E.g. if the current Bazel release is 7.1.x and I want to make multiple buildtools releases, they'll be called v0.7.1.0, v0.7.1.1, etc.
No, it is not unfortunately