Could you please do releases?

[darix]

There are already packages for the software and releases would make the life of a packager easier.

Thank you in advance.

[anthwlock]

Do you have a specific package repository in mind? Shouldn't it be possible to use the commit hash as the version, as untrunc --version is already doing it?

[darix]

well we have done a package for opensuse and we have seen packages for other distros. tags give a more userfriendly number.

revision numbers also are not incremental so an user can not easily see if they use the latest version

[anthwlock]

Do you see a way how this can be automated? Maybe one could take the number of commits as version? Or the date? I am fine with adding a new hook or the like, but I would not like have to manually maintain a version-number.

You probably are aware of this, but you could also just use the first n characters of the commit hash, which is already a bit userfriendlier than the entire hash (40 characters).

[darix]

short rev makes it more readable sure but it is still not sortable. what would make it more sortable if you would put e.g a tag on the first revision. then one could use git describe --tags where one field would be the commits since the first revision.

git tag 0.0.0 62e03b2
git describe --tags
0.0.0-292-gfcfd919

this would give us something we could use for sorting.

but tbh ... for a release this isnt this helpful as it wont trigger e.g. the release logic from github e.g. and packager and also websites which do release tracking work on real tags. so if you dont want to worry about things like semantic versioning ... just do simple ints as version numbers like systemd.

[anthwlock]

short rev makes it more readable sure but it is still not sortable

What about echo "v$(git rev-list --count HEAD)-$(git describe --always --dirty --abbrev=7)" ?

as it wont trigger e.g. the release logic from github e.g. and packager and also websites which do release tracking work on real tags

I would like to know what exactly you are trying to do (which service(s) are you using?), because maybe there are more elegant solutions. I don't like the idea of giving each commit its own tag, that's (IMHO) not what tags are for. But that's what I see end up happening, because the development currently just consists of little changes each now and then.

just do simple ints as version numbers like systemd.

But these would still have to be made manually, right?

[darix]

do you guarantee that every commit is something a normal end user should use or can it happen that you will need a few commits to get it right?

that's basically what it boils down to. and basically almost all distributions have the rule "ship releases".

[anthwlock]

do you guarantee that every commit is something a normal end user should use or can it happen that you will need a few commits to get it right?

Not necessarily every commit, but for every push.

and basically almost all distributions have the rule "ship releases".

Yes, and I also think that is a good thing for bigger projects. But if what ends up happening is "always tag after push", I don't see much of a benefit. Of course if your build system can only catch up on new git tags, I can see how using them would help. That's why I asked which (build/trigger) service/mechanism you are using.

The same issue occurred when starting to integrate snapcraft releases (#54), as it features different release channels, for which I just didn't see the use for in this project.

[nwparker]

You could do builds when a PR is merged into the master branch (if you use PRs). Github actions should let you set up this hook easy enough. Example:

on:
  # Trigger the workflow on PR on master branch
  pull_request:
    branches:
      - master

[anthwlock]

Github actions

This looks promising.

However I am still not fully convinced that creating a new release on every push would be the right thing to do. I understand that it could potentially make the packaging process easier for certain build systems, but I yet have to see a concrete example. Maybe if someone could point me to a concrete case, that would convince me.

As I see it, currently the packager can simply create a sortable version tag like this: echo "v$(git rev-list --count HEAD)-$(git describe --always --dirty --abbrev=7)"

[anthwlock]

In 3d11955f71e21af30940b58a06cc1ecb0bfe276c I made untrunc --version use the 'v\<N>-\<commit>' version scheme (where N := number of commits).

I will close this for now, since the discussion seems to have stalled