Hi,
I maintain the gnudatalanguage package on the aur. The current release is 0.9.9 (from 2019); however, there is 1.0.0-rc.3 available on their webpage.
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.
So the question is simply: Whould it be ok to push 1.0.0-rc.3 to the aur? And if so; how to specify the version tag correctly?
Thanks in advance!
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. After rc makes its way to a true release, that's when upstream is telling everybody that there's a new release to update to.
imho, if folks want release candidates, a VCS package could always be crafted. I would personally avoid releasing non-vcs rc packages.
At the end of the day; it's really up to the maintainer.
Regards, Kevin
On Fri, Jul 30, 2021 at 06:55:45PM +0200, Jan Kohnert via aur-general wrote:
Hi,
I maintain the gnudatalanguage package on the aur. The current release is 0.9.9 (from 2019); however, there is 1.0.0-rc.3 available on their webpage.
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.
So the question is simply: Whould it be ok to push 1.0.0-rc.3 to the aur? And if so; how to specify the version tag correctly?
Thanks in advance!
-- MfG Jan
Hi,
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
imho,
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.
Regards, Kevin
On Sat, Jul 31, 2021 at 02:28:45PM +0200, Jan Kohnert via aur-general wrote:
Hi,
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
Hi, Kevin is right, but it should be mentioned that it is specifically disallowed to put release candidates into a stable package. Exceptions can be read on the wiki [1].
Regards, Vince
[1] https://wiki.archlinux.org/title/Arch_package_guidelines#Package_versioning
Hi, Am Freitag, 30. Juli 2021, 23:12:01 CEST schrieb Vince via aur-general:
disallowed to put release candidates into a stable package. Exceptions can be read on the wiki [1].
[....]
[1] https://wiki.archlinux.org/title/Arch_package_guidelines#Package_versioning
Thanks for posting the link. I was uite sure having read this somewhere but couldn't find it anymore (I have been on the wrong wiki page).
On Sat, 31 Jul 2021 14:10:19 +0200 Jan Kohnert via aur-general aur-general@lists.archlinux.org wrote:
Hi, Am Freitag, 30. Juli 2021, 23:12:01 CEST schrieb Vince via aur-general:
disallowed to put release candidates into a stable package. Exceptions can be read on the wiki [1].
[....]
[1] https://wiki.archlinux.org/title/Arch_package_guidelines#Package_versioning
Thanks for posting the link. I was uite sure having read this somewhere but couldn't find it anymore (I have been on the wrong wiki page).
Not even packages in the official repository follow this rule - sometimes even pulling from git master - so there's nothing that strictly prevents you from packaging an RC on AUR.
And doing so because the old release can't be built without heavy patching sounds like a good reason (even the rule above covers that case).
Alad
-- MfG Jan
aur-general@lists.archlinux.org