search

speedata / publisher

speedata Publisher - a professional database Publishing system
https://www.speedata.de/
GNU Affero General Public License v3.0
292 stars 36 forks source link

Git repository missing tags for releases #550

Closed alerque closed 6 months ago

alerque commented 6 months ago

It would be helpful for downstream packagers if the Git repository were tagged for each release. Manually parsing commit history and finding a SHA to use for building released versions is tedious and error prone. Would you please consider tagging at release points?

pgundlach commented 6 months ago

Do you think of a special way to tag the releases? I'd think of release/v1_2_3 or something similiar. Would that be appropriate?

alerque commented 6 months ago

Why? My observation is that many projects start out thinking they want a scheme like that, but rarely do they actually end up serving a purpose. Meanwhile projects that just tag the release number with no fuss rarely have any issues with it. At most (and my personal preference) just using a v prefix for releases and then following everything after that with a semver parsable tag name serves me pretty well. If it doesn't start with v\d+.\d+.\d+ then it isn't a release tag.

alerque commented 6 months ago

In particular changing out the . separator for _ in your suggested scheme is particularly a nuisance downstream because it has to be parsed with a hand crafted replacement to get back to the matching version number of vice versa. Parsing the v prefix or not is pretty standard, everything else is the realm of every distro having to hand craft a regex to parse them.

pgundlach commented 6 months ago

I have never had any use for version tags, so that is the reason of my question. Would a release/ prefix harm? I assume so: you mention distros having to do custom parsing.

I need to find a way to put this in my build software.

alerque commented 6 months ago

No harm that can't be fixed, but why anoy people for no gain? With the vast majority of projects using it you aren't going to run into tooling problems with just using the release version as the tag. You already have a few old v3.x.y tags already, just keep up the trend. Changing scemes is far more likely to inconvenience far mor downstream folks than any scheme you do use consistently. 

$ git tag v4.15.19 7d1037fd
$ git push --follow-tags
pgundlach commented 6 months ago

I have now started to use tags. Hope that I will keep it up (half automated). Thank you very much for opening this issue and covincing me to just use va.b.c tags.