-
Notifications
You must be signed in to change notification settings - Fork 154
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
Comments
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? |
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. |
Yeah, devtools behaves the same as remotes AFAICT. |
For me and my team, it would be extremely valuable to have syntax in @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
|
@shikokuchuo pointed out that |
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. |
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 So on reflection, I completely agree with (and rely on) the current behavior of the 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 |
The text was updated successfully, but these errors were encountered: