GitHub Releases

[hmelder]

Hi,

are the GitHub releases still updated? Swift 5.5 seems a bit old to me considering that 5.9.1 is out on https://github.com/apple/swift

The releases are relevant for packaging.

[MaxDesiatov]

What are you looking for in GitHub releases specifically that you don't get from tags? Each snapshot and released version of Swift have corresponding tags on corelibs repositories, including libdispatch: https://github.com/apple/swift-corelibs-libdispatch/tags

[hmelder]

Yes but synchronisation becomes challenging when no release is created with the specific tag. Is it possible to also create a release along the way?

[MaxDesiatov]

Yes but synchronisation becomes challenging when no release is created with the specific tag.

Can you elaborate on this? What synchronization are you referring to? What exactly do you find challenging?

[hmelder]

Suppose I want to package libdispatch for a distribution like NixOS, or Debian. When sourcing from GitHub, the tooling leverages GH release information and notifies the maintainer about a new release. Just working with tags is possible, but inconvenient.

Other tooling might use the latest release tag from the repository which in this case is incorrect (stuck at 5.5).

The solution would be to either fetch the release tag from https://github.com/apple/swift and hope that it is also present in this repository (I guess you are synchronising tags across subprojects), or hardcode a release tag, and periodically check for new releases.

A tag marked as release would greatly simplify this process.

[MaxDesiatov]

Just working with tags is possible, but inconvenient.

Would you be able to clarify what exactly is inconvenient? AFAIK we didn't post release notes or changelog snippets in those GitHub releases that were posted (by accident I assume), so compared to tags creating new GitHub releases is just a duplication of work.

Other tooling might use the latest release tag from the repository which in this case is incorrect (stuck at 5.5).

IMO such tooling should be changed to rely on tags instead.

A tag marked as release would greatly simplify this process.

Tags that are actual releases are already marked with the -RELEASE suffix. Would filtering by that suffix resolve your issue?

[hmelder]

IMO such tooling should be changed to rely on tags instead.

So fetching all tags from the repository and filtering based on the way the tag is structured, and picking the latest one? This is one of the reason why releases exist in the first place: Providing a unified way of accessing the latest release tag (A gh release is nothing else then a referenced tag with some metadata and tarball). You could even use existing tags for the release or automate it.

My point is that every project that there should be a way to get the latest *-RELEASE tag. Can you point me to the section where I can find the tag?

[hmelder]

I guess the RELEASE tags are hidden behind all the snapshot tags

[MaxDesiatov]

A gh release is nothing else then a referenced tag with some metadata and tarball). You could even use existing tags for the release or automate it.

Tags on GitHub provide tarballs too. As I said, GitHub releases that were posted on some Swift repositories weren't a coordinated effort and most if not all of them didn't contain any release notes, so no additional metadata either. They were basically a duplication of some tags.

I don't think there's a need to automate creation of something that duplicates information that already exists in the form of tags.

My point is that every project that there should be a way to get the latest *-RELEASE tag. Can you point me to the section where I can find the tag?

Sure, feel free to run this in a clone of any of the relevant Swift repositories.

git tag | grep RELEASE | sort -r

If you need to get the list of tags without cloning, there's an API call for that: https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#list-repository-tags

[hmelder]

Is it possible to delete the existing tags or have an entry in the README to avoid confusion if you are reluctant to releases?

[MaxDesiatov]

Is it possible to delete the existing tags or have an entry in the README to avoid confusion if you are reluctant to releases?

I assume you meant deleting existing releases? Deleting tags would be out of question, since tags are the single source of truth.

If you mean deleting existing releases for consistency to always rely on tags instead, I'd like to ask @shahmishal first to clarify if this is something we should do at some point.

In the meantime IMO you should rely on tags in our repositories and not assume that releases contain any additional information.

[hmelder]

I mean the releases, sorry.

[hmelder]

In the meantime IMO you should rely on tags in our repositories and not assume that releases contain any additional information.

Yes, but since there are also releases this is confusing for people not familiar with the matter.