Tags without Releases

[shikokuchuo]

Need to investigate and handle e.g.

ERROR updating RcppSimdJson from https://github.com/cran/rcppsimdjson (Failed to find git reference '*release')

in the R-universe build logs.

Reverting this contribution in the meantime so the universe does not show a build warning.

[wlandau]

Strange, I thought the CRAN mirror automatically created releases. Under what conditions does it just create tags?

[wlandau]

Do you think we could post to https://github.com/metacran/metacranweb/issues?

[llrs]

It seems that for some packages (I checked some others like experDesign, or rtweet) it only generates tags but not releases. It doesn't seem related to name of how old the package is...

Might be worth checking and see if there is also a way to request r-universe to build on tags & releases.

[wlandau]

Might be worth checking and see if there is also a way to request r-universe to build on tags & releases.

I know it is possible to tag without a release, but is it possible to have a release without a tag? In the latter case, it might get ambiguous if we try to track both, or give the option of one or the other. But if releases always have tags, then it would be more inclusive to track the latest tag. We wouldn't have to rebrand, I don't think, but we could switch to tracking tags and it would solve this problem nicely.

[llrs]

I recently made a release with usethis::usethis::use_github_release() and it creates both. I think that git only allows tags but Github named them releases, but we would need to check it. Gitlab doesn't have releases but have tags, so I think this is Github specific.

[wlandau]

https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases says releases are based on tags. I just tested it, and the web UI does not allow me to delete a tag without deleting the release. So I think it's safe to use tags on github.

gitlab also supports releases, and deleting the tag also deletes the release: https://docs.gitlab.com/ee/user/project/releases/

So I think it's safe to rely on tags for us. Unfortunately, I am not sure R-universe supports tracking the latest tag (yet).

[wlandau]

Posted https://github.com/r-universe-org/help/issues/378

[wlandau]

On reflection... has anyone ever seen a Git tag used for a development version? I get the sense that Git tags are only ever used to mark release versions, but I want to be sure before we move in that direction.

[shikokuchuo]

I mean it's up to the maintainer what they denote as 'release' or devt version. But I've only really seen them used for version numbers.

See https://git-scm.com/book/en/v2/Git-Basics-Tagging

Perhaps some of the tags were lightweight tags and not annotated and hence the discrepancy we're seeing in when they are translated to releases in the cran GitHub org.

[wlandau]

I mean it's up to the maintainer what they denote as 'release' or devt version. But I've only really seen them used for version numbers.

Glad it wasn't just me.

See https://git-scm.com/book/en/v2/Git-Basics-Tagging

I think I'm now in favor of tags if we can track them automatically. Might have to ask for a feature in remotes because https://ropensci.org/blog/2021/06/22/setup-runiverse/#pro-tip-tracking-custom-branches-or-releasesis mentions it.

[wlandau]

Just posted https://github.com/r-lib/remotes/issues/200#issuecomment-1981805193. Sounds like they talked about it before and in principle it would be an easy change in remotes (just a different API endpoint).

[shikokuchuo]

I think I'm now in favor of tags if we can track them automatically. Might have to ask for a feature in remotes because https://ropensci.org/blog/2021/06/22/setup-runiverse/#pro-tip-tracking-custom-branches-or-releasesis mentions it.

Agree 100%. I'm finding as I'm adding more full dependency chains that especially some older packages only have tags, which I'm having to work round at the moment by using the CRAN mirror. Not too big an issue as these mostly seem to be mature packages and dependencies of actively-maintained and supported tidyverse packages etc.

[shikokuchuo]

Also is Gitlab currently off-limits until we move to tags? E.g. for https://github.com/r-releases/r-releases/pull/101 do we need to use the CRAN mirror as an interim measure.

[wlandau]

IIRC R-universe does support GitLab releases. The only reason I flagged GitLab PRs for manual review is that ncurl() gets redirected to the sign-in page. We could do something more nuanced like calling the GitLab API with an access token, but I thought GitLab repos were not common enough to be worth automating.

[shikokuchuo]

R-universe fails, see the logs at: https://github.com/r-universe/r-releases/actions/runs/8185714017/job/22382597652#step:3:372

Failed to find release for: https://gitlab.com/luke-tierney/codetools: A "branch":"release" is only supported github.com URLs

Switching to tags will probably allow us to better support Gitlab.

Gitlab requires a user authentication token for API use, which in the absence of a technical solution, means continuing to rely on manual review. I'm ok with this as Gitlab is an important platform to support.

[wlandau]

Hmmm that does pose a problem. I wonder how R-universe authenticates into GitLab.

I definitely agree we want to support tags on GitHub and GitLab (and Bitbucket if we can).

I will try and see if a "branch": "*tag" feature can be developed in remotes. Otherwise, I think it may be time for r.releases.internals::build_universe() to automatically fetch the latest tag using the APIs. I hesitate because that's tens of thousands of API calls, but we might have no other choice.

[wlandau]

Just posted a new issue: https://github.com/r-lib/remotes/issues/786.

[wlandau]

A couple potential caveats with tags, c.f. https://github.com/r-universe-org/help/issues/378#issuecomment-1981986053:

1. The concept of "latest" might not make sense for tags. We will need to investigate.
2. How do we detect and deal with tags on non-default branches?

[eitsupi]

Note that the latest tag is not necessarily the latest release. That is, things like rc versions may also be tagged, and such tags are usually newer than the latest release.

[wlandau]

Great point. And in those case, a release is a stronger endorsement than a tag.

So one path forward would be to continue tracking releases, but ask for support for GitLab.

[wlandau]

I see there is already an issue: https://github.com/r-lib/remotes/issues/570

[wlandau]

I wonder if another workaround is to mirror GitLab projects on GitHub and create releases there?

[wlandau]

To test how tags are listed in the GitHub API, I did an experiment using https://github.com/wlandau/tag-test. Here is what I did, in order:

1. Create tag v-feature in a non-default feature branch.
2. Create tag v1 in an upstream commit in the default branch main.
3. Create a tag v2 in a commit directly downstream of v1 in main.
4. Merge branch feature into main and create a new tag v-main-merge-feature.

Here is what I see in https://api.github.com/repos/wlandau/tag-test/tags:

[
  {
    "name": "v-main-merge-feature",
    "zipball_url": "https://api.github.com/repos/wlandau/tag-test/zipball/refs/tags/v-main-merge-feature",
    "tarball_url": "https://api.github.com/repos/wlandau/tag-test/tarball/refs/tags/v-main-merge-feature",
    "commit": {
      "sha": "66b8e213cbc61c7e3fe2f610352d964653d91476",
      "url": "https://api.github.com/repos/wlandau/tag-test/commits/66b8e213cbc61c7e3fe2f610352d964653d91476"
    },
    "node_id": "REF_kwDOLdESA75yZWZzL3RhZ3Mvdi1tYWluLW1lcmdlLWZlYXR1cmU"
  },
  {
    "name": "v-feature",
    "zipball_url": "https://api.github.com/repos/wlandau/tag-test/zipball/refs/tags/v-feature",
    "tarball_url": "https://api.github.com/repos/wlandau/tag-test/tarball/refs/tags/v-feature",
    "commit": {
      "sha": "36e3c382d87d9a1a44ed33777762f50e27aed4df",
      "url": "https://api.github.com/repos/wlandau/tag-test/commits/36e3c382d87d9a1a44ed33777762f50e27aed4df"
    },
    "node_id": "REF_kwDOLdESA7NyZWZzL3RhZ3Mvdi1mZWF0dXJl"
  },
  {
    "name": "v2",
    "zipball_url": "https://api.github.com/repos/wlandau/tag-test/zipball/refs/tags/v2",
    "tarball_url": "https://api.github.com/repos/wlandau/tag-test/tarball/refs/tags/v2",
    "commit": {
      "sha": "9b76abd0ee94afe8d0ac14faba504a40ddbfe817",
      "url": "https://api.github.com/repos/wlandau/tag-test/commits/9b76abd0ee94afe8d0ac14faba504a40ddbfe817"
    },
    "node_id": "REF_kwDOLdESA6xyZWZzL3RhZ3MvdjI"
  },
  {
    "name": "v1",
    "zipball_url": "https://api.github.com/repos/wlandau/tag-test/zipball/refs/tags/v1",
    "tarball_url": "https://api.github.com/repos/wlandau/tag-test/tarball/refs/tags/v1",
    "commit": {
      "sha": "f0862df449ab839b3c23adea2b35e9210209d9d2",
      "url": "https://api.github.com/repos/wlandau/tag-test/commits/f0862df449ab839b3c23adea2b35e9210209d9d2"
    },
    "node_id": "REF_kwDOLdESA6xyZWZzL3RhZ3MvdjE"
  }
]

So it looks like GitHub is trying to sort commits in topological order, which could allow tags in non-default branches to supersede ones in the main branch. This makes me think tags are no longer feasible for R-releases because they do not necessarily indicate production releases.

On the bright side, the order that tags are created does not seem to matter. It just matters the order the underlying commits are created.

I suspect that the reason people forget to put out formal releases is that there really hasn't been a need historically. People just submit to CRAN. This may change when we reach critical mass.

[shikokuchuo]

On the bright side, the order that tags are created does not seem to matter. It just matters the order the underlying commits are created.

Yes, this is an important property.

I suspect that the reason people forget to put out formal releases is that there really hasn't been a need historically. People just submit to CRAN. This may change when we reach critical mass.

Good point. Not just for this issue, but more broadly. Rather than a technological solution, sometimes it makes more sense to seek a human behavioural solution.

[shikokuchuo]

I wonder if another workaround is to mirror GitLab projects on GitHub and create releases there?

On this, I wouldn't mind if it were just the one repo. Otherwise doesn't seem to scale. We've only encountered one so far, and it's from R Core... I'd say let's prioritise the solution for Github first.

[wlandau]

So I propose:

1. Stick with releases.
2. Pursue https://github.com/r-lib/remotes/issues/570. Could use help on that.
3. Ask for releases in https://github.com/cran

Sound good?

[shikokuchuo]

Do we know who maintains MetaCRAN? That might give us an estimate if 3 would be feasible.

[wlandau]

Jeroen said Gabor does, and I have seen his name a lot in the commit history

[shikokuchuo]

Oh then definitely feasible :) Just if he has time or not...

[eitsupi]

I think it is common for package repositories using Git (such as Homebrew) to register a pattern of tags (or URLs) for each package and track them automatically.

But here it is overkill and the easiest thing to do is to get metacran to create GitHub releases.

[eitsupi]

Note that if you want to track Git tags from R, you can use something like the following using the gert package. This code has been tracking RStudio tags for several years on CI.

https://github.com/rocker-org/rocker-versioned2/blob/2db571dc64e401936ee14f64e454eaaba4f3d16f/build/make-stacks.R#L125-L134

.latest_version_of_git_repo <- function(remote_repo) {
  gert::git_remote_ls(remote = remote_repo) |>
    dplyr::pull(ref) |>
    stringr::str_subset(r"(^refs/tags/v?(\d+\.){2}\d+$)") |>
    stringr::str_extract(r"((\d+\.)*\d+$)") |>
    package_version() |>
    sort() |>
    utils::tail(1) |>
    as.character()
}

[shikokuchuo]

Thanks for the suggestion @eitsupi indeed gert is a great package - will have a dig in there to see what else might be useful for us.

[wlandau]

Thanks for the pointers on tags, @eitsupi. I think the branch ambiguity issue makes tags without releases a risky proposition, but it's still good for me to learn this stuff.

I just posted https://github.com/r-universe-org/help/issues/379 because I think it would be simple for R-universe to track GitLab releases. My post explains the specific API calls I found, and presumably R-universe can already authenticate into GitLab if it already gets commits and tags.

[wlandau]

As for the CRAN mirror, it might be easier to make an exception for this one instance and remove "branch": "*release" just for CRAN packages. The documentation says each separate commit is its own CRAN version: https://docs.r-hub.io/#cran-source-code-mirror. Indeed, https://github.com/cran/codetools has no releases (only tags) and versions in the commit history track with the CRAN archive.

[shikokuchuo]

Very good. This is the obvious solution that we've managed to overlook until now! Everything in the CRAN mirror is by definition a release, so we just need to take the latest one i.e. the R-universe default. We would just need to modify the internal utils package to accept this pattern when writing the packages.json.

[wlandau]

Sounds good. I am working on an update to r.releases.internals to:

1. Omit "branch": "*release" from https://github.com/cran repos.
2. Check GitLab releases. Making good progress on that, c.f. https://github.com/r-universe-org/help/issues/379

[wlandau]

Great news: we now have support for GitLab releases on R-universe! @jeroen really came to the rescue in https://github.com/r-universe-org/help/issues/379.

[wlandau]

Added support in https://github.com/r-releases/r.releases.internals/pull/12 to automatically merge GitLab contributions if they have releases.

[wlandau]

I think we have resolved our tags-vs-releases discussion for the time being.