Is there a specific reason was this changed? It seems useful to be able to check out a certain version of the source code, more useful than checking out an old version of the documentation site, which is stored as a directory per release anyway.
I see the same is true for safe_vault, where it changed around 0.3.0. Probably for other packages as well, but haven’t checked.
The reason I noticed this is that I wanted safe_ffi 0.4.5 specifically (as this is compatible with the current launcher), had to look up the commit in the log. Is there a better way?
I bet they just messed up. At this point, probably not. You have to get it at the commit hash you want. It is strange they did this…and strange it was done on two projects.
This is maybe a bug or intentional (I might get corrected by the team) due to rust / npm versioning. You should be able to check out a particular version or add this in your cargo.toml/packages.json. I would have thought git tags also worked though (git checkout tags/<tag_name> -b <tag_name>). I will take a peek as well though. @Krishna_Kumar may know more.
He is wondering why master wasn’t the one tagged, not whether it was tagged. If he were to checkout 0.5.0, he would be not getting the code branch but the GitHub pages branch.
Ah right, yes that’s a bug in our scripts then. We will get that resolved. There is a script runs when we do a PR with Version update to X.X.X it does a tag git, create the docs and prep for release (cargo release or npm). Something is not right there.
As @dirvine mentioned, this seems to a bug in our github tag deploy script where we seem to checkout to the gh-pages branch to update docs and generate tags in that branch than switch back to master before tagging. Cheers for highlighting this.
For now if you do wish to check out to a particular version you can use this command which should hopefully get you to the right point in history
so if you want to switch to version 0.4.5 of safe_ffi, it’d be something such as:
Thanks for bringing this up @wumpus. The script should be fixed now, so future tags should be applied correctly. I’ll see what I can do to rectify the damage I’ve done.