Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDRPlusPlus has switched to a "rolling release" model #52568

Open
agausmann opened this issue Oct 8, 2024 · 1 comment
Open

SDRPlusPlus has switched to a "rolling release" model #52568

agausmann opened this issue Oct 8, 2024 · 1 comment

Comments

@agausmann
Copy link
Contributor

agausmann commented Oct 8, 2024

The latest named version of SDR++ is 1.0.4, which is from 2021. However, it is still in development in "rolling release", where releases are not named, and a nightly tag is updated periodically from the main branch.

This hasn't been a problem on Void until recently, where for me, version 1.0.4 has started crashing at launch with the message Failed to initialize OpenGL loader!. I built the latest commit of SDR++ locally, and it does not have the same issue.

I would like to work on fixing this, but I am asking for input from maintainers on what direction you all would prefer:

  • Add an SDRPlusPlus-git package that follows the nightly tag
  • Update the SDRPlusPlus package to follow the nightly tag
  • Keep v1.0.4 and investigate the cause of the issue there. (Maybe it just needs a rebuild, or worst case it might need a patch.)

The last option is there because of this language in the void-packages CONTRIBUTING:

Software need to be used in version announced by authors as ready to use by the general public - usually called releases. Betas, arbitrary VCS revisions, templates using tip of development branch taken at build time and releases created by the package maintainer won't be accepted.

I'm not sure whether the nightly tag would be allowed. The SDR++ author recommends the main branch and the nightly builds, implying that it is continually "ready for use." But I'm open to working on 1.0.4 instead, if updating is not an option for packaging.

@tranzystorekk
Copy link
Contributor

We generally don't allow nightlies, betas, -git etc. Working on a fix for 1.0.4 is preferable (aside from maybe convincing upstream to cut releases every now and then?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants