chore: bump pkg version to v8.2.1#939
Conversation
|
Hey @antongolub thank you for addressing this so quickly! I thought of doing this PR, but (possibly a noob question, as I've never done release management on GitHub): isn't the release associated to a Git tag? Meaning: installs of the 8.2.1 tag/release will still have the incorrect 8.2.0 |
|
We use a pair of triggers to publish npm pkg: release tag and manual dispatch So, as soon as this PR is merged, the npm pkg will be published by click |
|
@antongolub Thank you for your reply; if that means the Git tag (and GitHub release) will be overwritten to point to the new commit, then that's fixed. (but I was under the impression Git tags don't get overwritten, hence the original question). Apologies for the noise. If this doesn't address my concerns, I'll have to pin by commit instead, which is ok. (full context of the original (#938) issue)Thenixpkgs package is built from source, based on the git tag; it's the mismatch between the Git tag and the package.json version that ends up being the problem in my particular case; I was under the impression that overwriting Git tags was not "common". Thank you!
|
|
We can just move the release tag to the next commit as an option too. |
Diff: google/zx@8.2.0...8.2.1 Changelog: https://github.com/google/zx/releases/tag/8.2.1 Temporarily pinning the commit which modifies package.json, as that affects the version reported by the CLI (causing `versionCheckHook` to fail). 0f2be5b053b7649fca84c92cd04310b94e297413~ == refs/tags/8.2.1 See: - google/zx#938 - google/zx#939
|
fyi, 8.2.2 is definitely in sync. |
|
@antongolub Thank you for the ping (and apologies for the spam above!). |
closes #938