Seeking volunteers - library authors who use GitHub releases

Hi All,

Now that our library updates section has been up and running for a while we will be expanding it by trialling automatic posting of library updates, where new releases will automatically get posted onto the forum under your username. It’ll only work if you use GitHub Releases with Markdown formatting.

You can see examples here:

If you would like to be part of the trial please PM @AstonJ with the following info for each library you’d like included:

  • URL of main thread in the libraries section (if you don’t already have one please create one first) :icon_biggrin:
12 Likes

Thank you for the references! I am bookmarking this thread and I’ll use the links as references when I do my first official library announcement on ElixirForum. Automating announcements of new releases makes a lot of sense and I love the initiative.

2 Likes

Glad you like the idea Dimi!

I don’t think there are any hard or fast rules tbh, and those examples were provided to give you an idea of long, med, short release notes (have re-ordered them now to make that clearer) of projects most of you would be familiar with. However what I would recommend is what most of you have already been doing in your library threads, especially now you know they can get cross-posted here automatically (probably the reason most release notes are usually succinct, because they don’t normally get automatically posted anywhere else) :icon_biggrin:

Here’s a good recent example of one that was using our Library Updates section:

Here’s another good example:

But there are loads of excellent examples in the Library Section :023:

3 Likes

What would be the object of the release though? I’m not sure it is particularly interesting to be able to download the source code as a zip for a library. What other benefits do we get from releases?

1 Like

I think it would be nice if we could avoid the GitHub dependency here. For one, alternative forges (e.g. Codeberg/Foregejo, SourceHut, Tangled) have been growing in popularity recently. As an example, the Zig programming language recently moved to Codeberg.

One thing I really appreciate about this community is that we have quality, sovereign infrastructure like Hexpm and of course this forum.

We already have structured release data from the Hex packages themselves, and we have a standard changelog.md format used by many popular packages and by Elixir. The changelog.md file is often rendered into the docs; here is Elixir’s changelog.

Given this, there should be a clear path to:

  1. Scan hexpm for new package versions
  2. Pull the changelog from hexdocs or the package files
  3. Parse the changelog and pull out the section headed with the version in question
  4. Use that data to generate a forum topic

This way we would only depend on Elixir infrastructure and make no assumptions as to which forge a package is using.

7 Likes

Totally off topic but having the README.md rendered on hex.pm would be nice too!

3 Likes

I’m not sure tbh - convenience perhaps?

The reason we need them to be GH Releases is because it’s (afaik) the only way we can pull the latest releases in via their Ruby gem (we’ll be using the Devtalk app to do this and DT is currently a Ruby app).

We’ll be using the Devtalk app to do this (it’s a Ruby app) so if any of the other platforms have a Ruby gem that work similarly we may be able to pull in from other platforms too.

We originally started using the GH gem to pull in repo info, eg:

Then started using it to pull the latest releases too. If other platforms have a Ruby gem we should be able to do the same for them too. Would be nice if they did.

Alternatively if we can pull in via RSS feeds.. but that would required customisation per platform (so probably won’t be part of the initial trial).

3 Likes

Good lord, github has ICE contracts? Guess I’ve been living under a rock and need to move. This one is gonna painful.

1 Like

My suggestion is to avoid direct dependency on the forges and to instead try to depend directly on Hexpm for the version and changelog data, which should be doable as I explained. Down the road it would be nice if Hexpm could expose structured changelog data.

If you start trying to add support for each forge individually this quickly gets messy as you suggest, especially since new forges (and self-hosted forges) are popping up left and right rn.

Slightly OT but I am very hopeful for Tangled in particular as ATProto has the potential to actually replace centralized platforms rather than just fragment them. I don’t think they are fully decentralized on ATProto yet but they seem to be taking it seriously.

3 Likes

If they stick to a standardised format it should be ok - iirc on DT we check for unique URL, so if two URLs match we assume it’s the same blog post. (Of course those platforms would also have to introduce something like GH Releases.)

Alternatively, Hex could do similar (via RSS) but I don’t know how much work that would be on their side..

1 Like

It’s slightly different for each forge. GitHub has first-class releases. Forgejo (Codeberg) is a GH clone and has what I assume to be nearly identical functionality (and an RSS feed). SourceHut and Tangled both seem to use tags as releases and allow you to attach artifacts to tags. The former has an RSS feed but the latter does not. However, Tangled is an ATProto-native app and by design has a very thorough API, so I imagine there is some way to get at them.

Git tags are involved in all cases, so that would be the unifying abstraction.

Hex should be able to quite trivially expose a feed of package versions if they don’t already. Changelog data is more complicated. They could parse the changelog.md files like I suggested but this seems a bit uglier as a first-party feature. Probably best to ask someone on the Hex team about this as I don’t have a deep understanding of the tradeoffs.

1 Like