willbryant/kitchen_sync

Add a --version ks command switch

Closed this issue · 6 comments

proby commented

It's been a minor annoyance to me that there's no --version flag you can pass to ks to get the version of ks.

proby commented

RE: #85 (comment)

I don't know my C++ buid systems much anymore. It seems like there should be a way to have a single version file (version.txt, version.h or whatever) that can get used for ks --version and can get used in the build system for setting a new git tag/release and for new bulid artifacts.

Getting hand-wavey here but you could make a new build target make release that builds the bins but also sets a new git tag/release (and thus can fail if the git tag/release) already exists. Basically does rake release exist in the C++ world?

I'm not sure what it should return on an "unreleased" commit (ie. not a specific tag). I assume everyone has this problem so would be good to understand how people normally deal with it. I do sometimes see versions like "git20200628-1" in Ubuntu packages, but I suspect someone does that manually.

Some relevant suggestions in this post: https://stackoverflow.com/questions/27395120/correct-way-to-encode-embed-version-number-in-program-code

proby commented

Maybe that CMake option given that ks uses CMake.

For another data point of versions are done, or printed at least:

~ rustc --version
rustc 1.44.1 (c7087fe00 2020-06-17)

version string + git SHA + date. I haven't looked into how they do that.

Looks super easy to get cmake to put the git tag (or parsed version numbers) into variables, or regenerate a file from template. This would avoid needing to remember to update the file.

I was about to charge ahead with doing that, but then it occurred to me that if someone downloads a tarball, that doesn't have .git/ in it so the tag isn't available from git.

The tarballs do however put all the files under a subdirectory with the tag in it, eg. kitchen_sync-2.5/. So I guess I could look for a git tag, and if there's no git repo, look at the current directory name. Not sure if this is a great idea or a terrible idea.

proby commented

Redis has a couple of scripts in a releasetools dir: https://github.com/redis/redis/tree/6.0/utils/releasetools but it looks like the change to version.h (https://github.com/redis/redis/blob/6.0/src/version.h) is manual.

I don't know what your release process is right now but I bet it could be turned into a little script. In that little script you could put a check and/or reminder to update version.h.

Cool, I'm gonna merge this PR and add a script to make the tag and update src/version.h.

To make that a bit easier I think I'll dumb version.h down a bit, hope that's cool. I don't even have patch version generally since I'm not maintaining old version branches.