Track the latest tag?

[wlandau]

"branch": "*release" tracks the latest release on GitHub or GitLab. Is there other functionality to automatically track the latest tag? In R-releases, we are finding that a lot of packages have tags but not releases, and it might be a lot to ask maintainers to create releases.

[wlandau]

We are also finding that https://github.com/cran is inconsistent around releases. All packages in there have tags, but not all have releases.

[jeroen]

The latter should probably be fixable by asking Gabor.

[jeroen]

Also, my experience is that not all authors use a practice of tagging releases. Some authors prefer to use a rolling release model, basically release by pushing into the main or stable branch. Would that be something you would want to support, where the upstream author can indicate that they release from a given branch, instead of tags?

[wlandau]

The latter should probably be fixable by asking Gabor.

At what level is "branch": "*release" implemented? Gabor maintains the package that does this, I presume?

Also, my experience is that not all authors use a practice of tagging releases. Some authors prefer to use a rolling release model, basically release by pushing into the main or stable branch. Would that be something you would want to support, where the upstream author can indicate that they release from a given branch, instead of tags?

Yes, I have seen that too. But I am concerned by how fluid non-default branches can be for most projects. Because R-releases aims to reach such scale, I would prefer tags because they are transparent and obvious without needing to understand each individual maintainer's own development workflow.

[wlandau]

Along those lines, I actually wonder how reliable tags are to indicate releases. I have never seen a Git tag for a development version, but I wonder if people do that.

[wlandau]

At what level is "branch": "*release" implemented? Gabor maintains the package that does this, I presume?

https://ropensci.org/blog/2021/06/22/setup-runiverse/#pro-tip-tracking-custom-branches-or-releases mentions remotes, so I will file an issue there.

[jeroen]

At what level is "branch": "*release" implemented? Gabor maintains the package that does this, I presume?

Sorry I meant that gabor maintains github.com/cran and he can probably fix that the latest releases automatically are tagged as latest.

The "latest" release is a github concept. When you tag a release you choose to make it the "latest". We actually implement the API call to lookup the latest release here: https://github.com/r-universe-org/sync/blob/bc8d3051cdc7c3b48c5d6ad9a9584b2fdddd595d/R/monorepos.R#L592-L605

If there is no "latest" release, we could try to get the most recent tag from e.g. this api: https://api.github.com/repos/apache/arrow/tags however tags may not be chronological. So if the author would tag a patch version of some older tag release, you might get that one I think?

[wlandau]

If there is no "latest" release, we could try to get the most recent tag from e.g. this api: https://api.github.com/repos/apache/arrow/tags however tags may not be chronological. So if the author would tag a patch version of some older tag release, you might get that one I think?

So close yet so far... definitely worth looking into though. I wonder if e.g. the date and time are query parameters.

It also occurred to me that tags could be created using different branches. I wonder if there is a way to get just the tags of the default branch.

[wlandau]

My experiments show chronological order is respected within a branch, but I think the API tries to sort commits in topological order across all branches. This could allow non-default tags to supersede tags in the main branch, which could potentially put unstable releases in R-releases. I will have to discuss with the rest of the team, but to me tracking tags for R-releases no longer seems feasible.

[wlandau]

So I think we're keeping the releases-but-not-tags route after all, c.f. r-multiverse/help#26 (comment). Closing this thread.

[wlandau]

The "latest" release is a github concept. When you tag a release you choose to make it the "latest". We actually implement the API call to lookup the latest release here: https://github.com/r-universe-org/sync/blob/bc8d3051cdc7c3b48c5d6ad9a9584b2fdddd595d/R/monorepos.R#L592-L605

Ah, thank you, this really helps me understand where things are happening. It would help to track GitLab releases too, but I will open a different thread for that.