search

zorchenhimer / MoviePolls

Voting to decide on a movie to watch with MovieNight
https://discord.gg/F2VSgjJ
16 stars 6 forks source link

Added compile time variables for version and commit #107

Closed CptPie closed 3 years ago

zorchenhimer commented 3 years ago

After thinking this over a bunch, replacing standard spaces with non-breaking spaces really rubs me the wrong way. Although it would be nice to have the latest commit message in the version printout somewhere, is it really necessary? I think I might prefer just the commit hash.

If you're dead set on having the message in there, I think I would prefer a script that generates a source file that just defines the version variables.

Also, thoughts on using semantic versioning where the patch number is the commit count since last minor version? IE, given v1.2.3, 1 is the major, 2 is the minor, and 3 is the number of commits from the v1.2 tag. We could even put the commit has in there too, making it something like v1.2.3_e58c437. Going a step further, we could even append if the repo has uncommitted changes at build-time: v1.2.3_e58c437_dirty. For reference, this is how I added commit info to the version in another one of my projects: https://github.com/zorchenhimer/steam-screenshots/blob/master/releases.pl#L12

CptPie commented 3 years ago

After thinking this over a bunch, replacing standard spaces with non-breaking spaces really rubs me the wrong way. Although it would be nice to have the latest commit message in the version printout somewhere, is it really necessary? I think I might prefer just the commit hash.

If you're dead set on having the message in there, I think I would prefer a script that generates a source file that just defines the version variables.

I am not really that hard set on the commit message (even though it would be nice to have) and i totally see your point with the nbsp instead of the normal space.

Also, thoughts on using semantic versioning where the patch number is the commit count since last minor version?

I like the general idea of your proposed versioning system but wouldnt it be bothersome to do this versioning by hand (i.e. counting the commits), also which commits to count in the first place (i.e. commits on master vs all commits) and going even deeper, will we squash prs then or how to handle larger prs?

zorchenhimer commented 3 years ago

I don't plan on doing anything manually. After a quick search, git describe --tags does basically what I was thinking. On the current HEAD it will return v.0.1-3-ge58c437.

As for the multiple branch question, I'm not really sure that would be an issue. I don't plan on running any binary that isn't built off of master. If that changes we could probably inject the branch name into the version somewhere.

CptPie commented 3 years ago

I don't plan on doing anything manually.

Maybe let me rephrase my concern: How would you "automate" the x in v.0.1.x if x is the number of commits since the last minor version? Is there an automated way to determine the amount of commits since the last tag or would that have to be done by manually counting.

zorchenhimer commented 3 years ago

The output of git describe --tags does exactly that. From the docs (emphasis mine):

The command finds the most recent tag that is reachable from a commit. If the tag points to the commit, then only the tag is shown. Otherwise, it suffixes the tag name with the number of additional commits on top of the tagged object and the abbreviated object name of the most recent commit. The result is a "human-readable" object name which can also be used to identify the commit to other git commands.

CptPie commented 3 years ago

Gotya - verified that behaviour just now - that works fine with me

CptPie commented 3 years ago

image Thats the current implementation.

I think it would be nice to execute the server with a --version flag which prints the current version and exits but I have no idea how to do that since TBH I am not sure where the entry point of this project even is lul