Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix @*release #200

Closed
gaborcsardi opened this issue Oct 11, 2018 · 8 comments
Closed

Fix @*release #200

gaborcsardi opened this issue Oct 11, 2018 · 8 comments

Comments

@gaborcsardi
Copy link
Member

❯ 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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member Author

Yeah, devtools behaves the same as remotes AFAICT.

@wlandau
Copy link

wlandau commented Mar 6, 2024

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
Copy link

wlandau commented Mar 7, 2024

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

@wlandau
Copy link

wlandau commented Mar 7, 2024

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
Copy link

wlandau commented Mar 7, 2024

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
Copy link

wlandau commented Mar 7, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants