Repository navigation
allow snapshot releases to use commit hash as tag #573
Description
Affected Packages
pkg:cli
Problem
Right now snapshot releases use a timestamp as the extra unique identifier that is appended to the version. This is a good idea in theory to make them unique, but in practice it makes it really hard to figure out which release maps to which commit (especially when setting up an automated workflow to make a dev channel release for every commit to main).
Proposed solution
I think there should be an option (or make the change completely) to have the latest commit hash the identifier instead. So you'd end up with releases like:
1.3.3-1fe6d0c
1.3.3-25a6994
An example of this pattern in the wild is that @headlessui uses it:
And it has been nice to work with as a consumer.
Reacted by with-heart and William Lee
Activity
Andarist commentedon Apr 16, 2021
Slight problem with that approach is that there is a hidden caveat that people dont realize. Prerelease segment of the version (where the hash would be) is comparable alphabetically and some random/older version could potentially be installed instead of a newer one. Locks usually guards alus from this but it can happen and I've seen it happening accidentally.
ianstormtaylor commentedon Apr 16, 2021
@Andarist I'm not totally sure I follow. Do you mean it's compared alphabetically when someone is doing an install at a specific version (ie. not using the tag
dev)? Just wondering because I don't think I've run into it, but I'm always doingyarn add x@devoryarn upgrade x@dev.Andarist commentedon Apr 16, 2021
One case that is easy for me to mention specifically (as its about public packages) is that some people got this installed https://github.com/ReactiveX/rxjs/releases/tag/6.0.0-smoosh.0 over this https://github.com/ReactiveX/rxjs/releases/tag/6.0.0-rc.1 . Even though they have wanted to install the rc (which was newer). How exactly did this happen for them - im not sure. Maybe they just put
^6.0.0-rc.1in theirpackage.jsonand tried to install without a lock?im not saying that im completely opposed to the idea - its certainly popular and convenient, just also associated with this caveat and it was a specific reason why we have chosen the date as the suffix
TheSpyder commentedon Apr 16, 2021
The other thing using the hash does is makes it difficult to know what order versions were published in. It is certainly possible to sort versions by publish date but it's not usually the default.
The way I've tackled this in the past (on an internal project) is to use both the timestamp and hash, e.g.
1.3.3-2021316102044.1fe6d0cianstormtaylor commentedon Apr 17, 2021
The timestamp+hash route is also interesting because it means we could have shorter time stamps which are easier to read as time stamps when scanning—like
2021.09.31.13ed370.Andarist commentedon Apr 17, 2021
This should actually be already possible with smth like:
changeset version --snapshot $(git rev-parse --short HEAD)See here:
https://github.com/atlassian/changesets/blob/de2b4a5a7b244a37d94625bcb70ecde9dde5b612/packages/assemble-release-plan/src/index.ts#L39
Although it actually would put that hash before the date and not after - so close to the original request but in the end, I'm not sure if that's the best as it creates the mentioned problem with sorting.
Publish snapshots of the modern packages on every commit
stabas commentedon Sep 2, 2024
bluwy commentedon Jul 1, 2026
This is supported with the
snapshot.prereleaseTemplateoption added since #858