Odd release handling makes it almost impossible to maintain a Linux package

[r7l]

It might be related to time issues by the maintainer, which i can fully understand. But still, the release handling in Redlib is odd recently.

The issue is that instead of creating new releases, Redlib started to replace binaries in the most recent release. But the release still points to this commit.

It makes it pretty hard to provide a package for a Linux distribution that relies on the source code. In this case Gentoo Linux, for which i am trying to keep a package going but i am not able to easily provide one anymore.

The way packaging in Gentoo works is by creating a copy of the released lock file into the package file. This is because they discourage the idea of sideloading dependencies during the build process. So the package manager will deal with this instead of Rust. There are several tools (in this case Rust) for this process for each of these languages using lock files.

Replacing the source files in the old release wouldn't help. As this would just break checksums and lock files.

It's not just Gentoo btw. as i've just checked Arch Linux and they've got around this missing release by adding a patch their most recent release. They are not having the sideloading issue with dependencies, which seems to make it easier for them. But still, they will no longer follow new releases as Github will not trigger release notifications. So in general, people might not update their Redlib instances and 3rd party package maintainers will not update as well.

I am sorry to complain about it as i really like this project and was waiting out for a new release. In the past, it wasn't an issue. New releases were done quickly but i've noted another binary replacement earlier and wanted to point out the side effects.

[sigaloid]

Ooh. I didn't notice that was still a problem. That should be an easy fix to the github actions to not replace the binary unless it's a tagged release. Thank you for reporting!

[laszloszurok]

I took a look at the github workflows to see what's going on. I see this action is used: softprops/action-gh-release@v1 to create releases and upload binaries to it. If I understand correctly, the overwriting of the binaries in the latest release could be fixed by adding a condition to the release step:

if: startsWith(github.ref, 'refs/tags/')

But I guess we could also automatically create new releases every time the workflow runs. I don't know if that would be desirable. Also github cli could be used instead of the unofficial action to create the release. For example:

- name: Upload release
  run: |
    gh release create ${{ steps.version.outputs.VERSION }} \
      --draft \
      --title ${{ steps.version.outputs.VERSION }} \
      --generate-notes \
      /path/to/archives

[r7l]

Given the nature of events recently, i fully understand the situation for not doing a proper release management. Even so, creating a new release for each commit would be a better solution then what is done currently. At least for 3rd party people trying to maintain packages for Linux repos.