Maintain two packages. One being your stable package, at 0.9.9, and one being a VCS -git suffixed package, that allows users to use rc (or master or whatever) if they really care about it. But, to be short here: if 0.9.9 is the current release, the out of date flag is frankly incorrect.
Sounds like the upstream maintainer just needs to push out the release. There's got to be some reason they have not.
On Sat, Jul 31, 2021 at 02:28:45PM +0200, Jan Kohnert via aur-general wrote:
Am Freitag, 30. Juli 2021, 22:54:04 CEST schrieb Kevin Morris via aur-general:
On Fri, Jul 30, 2021 at 06:55:45PM +0200, Jan Kohnert via aur-general wrote:
I recall having read somewhere in the docs that pushing rc version is generally discouraged on the aur, but got a out-of-date flagging today.
If 1.0.0-rc.3 is why they're flagging it out of date, perhaps you could reply to them and explain why it's not out of date; an rc is a release candidate, but not necessarily a true release.
the RC we're talking about has been build mid last year, since then no new releases have been pushed (they do weekly (release-)builds, though). Version 0.9.9 OTOH has been quite heavily patched to be able to build and run on current arch (I included upstrean python3 patches, as well as a graphicsmackic patch); patching would not be neccessary using the current RC.
I also have been working on an updated package last year in a local branch, since I was hoping a 1.0.0 release to have been happened sometime last year...
imho, if folks want release candidates, a VCS package could always be crafted. I would personally avoid releasing non-vcs rc packages.
A vcs pakage would use current git; and since in the end folks tend to use astronomical software to publish papers; it could be disadvantageous to use a possibly broken git version. OTOH, this holds true for RC releases, too; though they might have been tested better .
So, I'm still unsure what to do...
Best regards, Jan