Why are all releases marked pre-release?

[echoix]

I had a small curiosity here, as to why all releases are marked as "pre-release" in the repo's releases, all 23 of them since 2019.
This makes the repo appear to have no releases when looking at the repo's home page.
It makes the version 0.9 appear as the first choice in the GitHub marketplace when trying to see how to set it up (as no other versions would be latest, and if we consider that there is an alphabetical sort for the pre-releases, 0.9 is before 0.18).
It also prevents tools like dependabot or like what we use, renovate, to trigger an update for users using older versions.

Is there a reason that is more important than these 3 impacts to keep them "pre-release"? If we keep strict semver meaning, versions 0.y.z can be breaking whenever we want without a contract of any kind.

[DoozyX]

Thanks for raising this concern.

When I initially started this GitHub Action, it was part of an evolving project that I was actively using in my work. At that time, I marked all releases as “pre-release” to signal that the project was still under active development and that there might be breaking changes or instability.

I realize now that marking all releases as “pre-release” may no longer make sense, especially given the impacts you mentioned. Considering these points, I agree that it might be time to reevaluate the “pre-release” status of these versions, particularly if they have been stable and widely used without issues.

I have just removed the “pre-release” tag from the latest version to address these issues. Please let me know if it works fine now.

Thanks again for bringing this up and I appreciate your input.

[echoix]

Thanks! I can't help you to know if renovate would suggest an update, as I just manually updated the hash yesterday, so it's already up to date.

[echoix]

I have another repo that wasn't updated (a fork), with renovate enabled, but probably for caching reasons it doesn't trigger and stays at v0.17. I can however confirm that the page on GitHub marketplace displays a more useful latest version, and that releases are shown on the GitHub page :

[echoix]

I can confirm today that I got multiple renovate updates, including some digest-only changes. Was the precise tag overwritten for v0.18.1?
I see a diff for v0.18.1 for caa1792 being changed to v0.18.1 for
c71d0bf

OSGeo/grass-addons#1198

There’s also a run (and rerun) for v0.18.2 that now fails (the one for v0.18.1 doesn’t fail): https://github.com/OSGeo/grass-addons/actions/runs/10707503673/job/29696447663

It says:

run-clang-format.py: error: unrecognized arguments: .

Where . Is the source parameter.

[echoix]

A same tag overwrite seems to have happened for v0.18.2:

-      - uses: DoozyX/clang-format-lint-action@94868e2fbaf644772a7d228aa605670221ac7b26 # v0.18.2
+      - uses: DoozyX/clang-format-lint-action@c71d0bf4e21876ebec3e5647491186f8797fde31 # v0.18.2

[DoozyX]

Could you try rerunning the again on v0.18.2, that should have happened for a couple of minutes but pushed later a replacement tag for that fix.

Yes I updated most recent version tag to include a hotfix for the docker version since it wasn't pinned correctly