silverqx
commented
10 months ago At sure that's what I should do, I will do it for the next release this way and also I will create a few GitHub releases for previous TinyORM versions. It's a good thing.
But, I still don't understand one thing and that's this.
Currently TinyORM, TinyORM has to push a commit to bump the Changelog (e.g. dddc80c), and then add the commit hash that is generated only when this commit is done into vcpkg's port (e.g. bc58b56).
I bumped version numbers everywhere, then I need to edit portfile.cmake, the REF will look something like this REF v0.35.0 instead of commit hash but how will look the SHA512? How this should look for the v0.35.0 release? Simply, I don't understand how can I do it in one commit.
vcpkg_from_github(
OUT_SOURCE_PATH SOURCE_PATH
REPO silverqx/TinyORM
REF v0.35.0 # 3e207861
SHA512 0
HEAD_REF main
)Tagging the commit that finishes the release phase will enable quickly reverting/forwaring rather then having to look up the git commit history to find commits increasing the tinyorm version, then looking "behind" the commits to find the commit that concludes the release.
You are talking about git checkout or switch right?
SchaichAlonso
Hi
Git supports tagging commits in order to give them "human readable" labels (rather then sha256) which can be checked out like the commit hashes, but since only a few commits are "release" commits, the number of tags is quite limited compared to the number of commits.
Tagging the commits also enables git describe, which can be used to annotate documentation by the commit it relates to, to do a "better" job.
Further, GitHub will enable quickly looking up tagged commits by listing the tags next to the branches in the code overview and in the branch selection dropdown. While a tag isn't a release, in projects that have no formal releases, tags will be shown on the code overview's "Releases" tab.
Currently TinyORM, TinyORM has to push a commit to bump the Changelog (e.g. dddc80c), and then add the commit hash that is generated only when this commit is done into vcpkg's port (e.g. bc58b56). Tagging the commit that finishes the release phase will enable quickly reverting/forwaring rather then having to look up the git commit history to find commits increasing the tinyorm version, then looking "behind" the commits to find the commit that concludes the release.
Also, once pushed, git tags can be turned into GitHub Releases within a few clicks only.
Most users will only want to use "released" code, so the tags / releases will help them identify whether there is a new release available in case vcpkg isn't used (e.g. by submodule-ing TinyORM into the consumer repository and add_subdirectory-ing it in order to integrate it into the consumers' build process, or by checking it out elsewhere and manually installing it).