`closing-remarks`: options to exclude pre-release tags (feature request) about refined-github

[fregante]

A couple of issues with that:

• stable or not, if it's tagged, generally you can install it, or expect it to appear soon in the non-beta version
• the feature targets tags, which are widely used, not github releases, which are the only ones with the "pre-release" flag

I don’t think I want to overcomplicate this with logic that may vary across repos. The feature answers that question alone and it can't afford to make guesses around which tag the user prefers to see.

Considering that probably there isn't even an API for this (i.e. get the tags that contain this commit), we can't even begin to consider releases.

[wookayin]

Thanks for your help and support! Yes, I do see that this is blocked by a technical limitation that the current Github REST API lacks something like git name-rev.

A side note is that, if this feature worked as you intended (as in #7208) then it should have shown "v0.9.0" instead of "nightly". So it's the same issue as #7208 -- nightly is shown because it is the alphabetically (not chronologically) the first tag that contains the commit, coming earlier than v..., due to the current way how the tag information is fetched (branch_commits). If this worked as intended, showing candidate versions, or moving tags (nightly), doesn't really matter, so I would not need this feature too in the first place. For the simplicity, not excluding the pre-release tag would be better, as you said and I can fully agree with that. All I wanted to have is to NOT see the (useless) nightly tag; but it turns out that the reason it was showing up is not because it's a pre-release tag that had existed earlier than the full release, but because it's the lexicographically first tag.

[fregante]

That's a misuse of tags that causes conflicts at every push/pull, see note in https://stackoverflow.com/a/19300065

nightly should be a branch because that's that they're for.

[fregante]

It would be even better if users can configure explicit patterns to ignore tags

We can't add options to Refined GitHub, see:

https://github.com/refined-github/refined-github/wiki/%22Can-you-add-this-feature%3F%22#3-it-doesnt-require-options

[wookayin]

I see, I understand that options are too much burden.

But I respectfully disagree that nightly should be a branch not a tag, because "nightly releases" are "releases". Who cares a nightly tag causes a conflict? Clobbering existing tag can be easily dealth with git fetch (no tag fetching) or git fetch --tags --force should be of practically no problem.

UPDATE: Even if one uses a different, unique tag name for each nightly release; say nightly-20240101, closing-remarks will still show "This PR first appeared in nightly-20240101" which is still not useful information, as the version is a "pre-release" not a stable "release".

[fregante]

The main issue is that this feature answers the question:

• has this PR been released yet?

Pre-release is literally a release. If 1.0.1-beta includes the PR, should we said "This PR hasn't been released yet"? Because that sounds like a lie/wrong.

I'd potentially classify nightly releases as releases, but maybe we can make an exception because you probably still want to release manually later.

Perhaps we can:

• exclude tags that include "nightly" in their name
• exclude tags that don't include numbers

[wookayin]

People would be mostly looking for:

• Has this PR been released yet -- in a stable release?

while some might be also interested whether the PR has appeared in any pre-release versions (e.g. snapshot versions or release candidates).

Checking the tag name/pattern such as nightly or digits would work (#7208) but this might too specific given that you don't want to allow options; there might be many corner cases. However, in Github releases there is a very clear binary signal telling: Pre-release v.s. normal/stable/full release. (See #2239, #2905, Manage releases - item 10, and Releases REST API - prerelease boolean field) So I think excluding pre-release would make a sense, and this would have the same principle as #2905.

So my proposal is: to show either the first non-pre-release, the first pre-release as a fallback (if there is no stable release out), or both.