Suggestion: create a GitHub release after pushing each tag

[aantron]

This allows GitHub to notify GitHub users of releases, if they are watching the repo for Releases only (at least, as I understand it).

The release text can be empty. Another easy option is to paste in the tag message.

My apologies if this has been suggested in the past; I searched only this repo.

[cjihrig]

Are these - https://github.com/libuv/libuv/releases - not getting the job done?

[aantron]

I don't think so, though it's possible that I'm not receiving emails for some other reason. I'm under the impression that the emails are only sent after using "Draft a new release."

[cjihrig]

If releases are created, but notifications aren't sent out, that sounds like a bug on GitHub's side. I'm hesitant to introduce more manual steps into the release process.

[saghul]

As someone who did releases in the past, I agree with @cjihrig here.

[aantron]

I'm speculating, but I don't think those are GitHub release objects, they are "just" tags that GitHub is displaying on the releases page due to the lack of GitHub release objects. Compare these two pages:

https://github.com/libuv/libuv/releases/v1.30.1
https://github.com/ocsigen/lwt/releases/4.2.1

The libuv "release" says "cjihrig tagged," while the Lwt "release" says "aantron released." Note also that on the libuv object, the "Tags" tab is highlighted, but on the Lwt object, "Releases" is highlighted.

The difference is that the Lwt release was created using "Draft a new release," which allows to create a release for a tag. I think this is what is necessary to get GitHub to send an email.

And here is a releases list from some project of mine, in which I didn't do GitHub releases at first, but then started: https://github.com/aantron/better-enums/releases. There, you can see the difference between what GitHub considers a release (the most recent two objects), and a tag that doesn't have a GitHub release associated with it.

[aantron]

This brief page seems to confirm: https://help.github.com/en/articles/about-releases

[cjihrig]

@aantron I think you're right. It looks like this is a long standing source of confusion: https://github.jparrowsec.cnmunity/t5/How-to-use-Git-and-GitHub/Tag-without-release/td-p/6255.

[aantron]

Yes, I'm also learning a lot more about the subtleties now, from discussing this issue :)

[aantron]

...perhaps the most immediately relevant of which would be that I think it's best not to go back and create releases for existing tags, but only to start with the next tag (if you choose to do it, of course).

[cjihrig]

I've moved this issue to the libuv-release-tool repo, as any changes to the release process would need to happen here.

[richardlau]

I've moved this issue to the libuv-release-tool repo, as any changes to the release process would need to happen here.

This issue could probably be solved now with GitHub Actions and the create-release action.

[aantron]

I'd welcome that. I recently released the binding I was working on. My current way of checking for libuv releases is to manually poll the release page weekly. That's not difficult, but it would be nice to simply get an email, like sent by many other projects I monitor.

[aantron]

Note that the binding is creating proper releases.

[aantron]

After the latest GitHub redesign, this is what is shown in the "releases" section on the main page of a project that does releases:

This is what is shown on libuv's page, because it does not do releases:

As before, because libuv does not do releases, it is still not possible to use GitHub's support for receiving emails about libuv releases. This does nothing for libuv:

By comparison, as one concrete example, I monitor the releases of Dune, a build system I use for the first project I linked. You can see its releases page with neat, hyperlinked release objects. I receive email-rendered versions of these upon each release. You can also see Dune's latest release info at a glance on its main page.

I also monitor releases of Windows Terminal, which I use with WSL. Windows Terminal is a very popular project that uses GitHub releases to communicate with its users.

To mention myself, I use GitHub releases in all my user-facing repos. When GitHub itself added support for receiving emails on releases only, we were able to retire an announcements issue in a major OCaml project I was maintaining at the time.

There are very many other examples. I argue the above points show that creating release objects is the intended way to use GitHub.

At minimum, I think you could simply (automatically?) paste the tag texts from your current practice into release objects. They won't be so neatly hyperlinked as for the projects I linked, but they are already formatted as Markdown lists, and that will at least trigger email notifications. The two lines at the top of each tag's text will already be interpreted correctly as two separate lines by GitHub-flavored Markdown. I suggest doing this starting from the next tag, so as not to trigger notifications at this point for older releases.

And I'd like to request properly that libuv start making release objects on GitHub :)

[aantron]

Great, many thanks! I got the email notification!

[aantron]

Only recommendation would be to paste the changelog into the release text; however, I already know where to find it, so it's fine for me not to. May be helpful for other people watching.