Fix @*release

[gaborcsardi]

❯ install_github("r-lib/R6@*release")
Error in github_resolve_ref.github_release(meta$ref %||% ref, meta, auth_token) :
  No releases found for repo r-lib/R6.

[gaborcsardi]

So often times people just create tags and not real releases. Quite confusingly these show up here: https://github.com/r-lib/R6/releases

But not here: https://api.github.com/repos/r-lib/R6/releases

In the API, you need to query https://api.github.com/repos/r-lib/R6/tags to get the tags.

remotes currently uses the real releases only. I think it would make sense to use all tags, maybe?

@jimhester ?

[jimhester]

This feature is so rarely known / used I am not sure it is even worth fixing this edge case, it is also somewhat more correct to only use proper releases, although I often forget to make them as well.

[gaborcsardi]

Yeah, devtools behaves the same as remotes AFAICT.

[wlandau]

For me and my team, it would be extremely valuable to have syntax in remotes to get the latest Git tag, regardless of whether a GitHub release actually exists.

@shikokuchuo, @llrs and I are working on R-releases, a new project that began in the R Consortium Repositories Working Group. We have lofty ambitions to curate Git releases across the entire R package ecosystem in one central R-universe, but we are finding that many maintainers create Git tags without GitHub releases, and that makes things difficult for us. C.f. r-universe-org/help#378

If I understand correctly (@jeroen please correct me if I am wrong), R-universe uses remotes to track references. So if remotes were to adopt notation to track the latest tag, then R-universe could pick that up right away.

It would be the most seamless for me and my team if the existing *release notation could get tags instead of releases, but I understand if this would be considered a breaking change (or not entirely correct, as you discussed above).

[wlandau]

@shikokuchuo pointed out that *releases seems to be for GitHub only. So maybe my comment above belongs in a separate issue.

[wlandau]

It would be the most seamless for me and my team if the existing *release notation could get tags instead of releases, but I understand if this would be considered a breaking change (or not entirely correct, as you discussed above).

Actually, we are still discussing whether tags are feasible for our purposes in R-releases at all. So it would be useful to distinguish between latest tag and latest release. I like how the "*release" ref currently works in the GitHub case.

[wlandau]

The concept of a "latest release" makes sense, but I don't think the concept of a "latest tag" makes sense because of the possibility of tags in non-default branches.

r-multiverse/help#26 (comment) describes an experiment I did with https://github.com/wlandau/tag-test. The v1 tag was created in the default branch main, and the v-feature tag was created in a non-default branch in a commit downstream of v1. In https://api.github.com/repos/wlandau/tag-test/tags, v-feature takes precedence over v1 even though it could be unstable from a package release standpoint.

So on reflection, I completely agree with (and rely on) the current behavior of the "*release" reference syntax: just get the latest formal release, ignore tags.

But it would be really nice if this were supported for GitLab: #570

[wlandau]

But it would be really nice if this were supported for GitLab: #570

Actually, from r-universe-org/help#378 (comment) this seems to be handled from R-universe directly. So even that is not a remotes issue.