Support latest version

[Schultzer]

Description

This PR adds support for the latest version; I'm not super familiar with the codebase, so it's not the prettiest, and the tests are doomed to break when there is a new release.

@paulo-ferraz-oliveira Please let me know if this is the right direction.

Closes #266

• [x] I have performed a self-review of my changes
• [x] I have read and understood the contributing guidelines

[paulo-ferraz-oliveira]

If we want to support this we need to do it for all dependencies we maintain (includes Gleam, rebar3, etc.), for feature parity.

[paulo-ferraz-oliveira]

the tests are doomed to break when there is a new release.

We're usually up-to-date with newer releases, and update the action to test those, where appropriate.

[paulo-ferraz-oliveira]

I have read and understood the contributing guidelines

This states "Execute npm run build-dist and fix any issues arising from that". I can't understand what failed that it didn't generate any artifacts that you'd need to push, for which CI complained later, for example here.

[Schultzer]

Thanks, @paulo-ferraz-oliveira I've cleaned this up.

[ericmj]

Should it be the latest stable version or include pre-releases?

You need to fetch the latest version from the same source we get the other versions, otherwise the task will fail when there is a new release as it's tagged before the builds are available (at least for elixir and erlang).

[Schultzer]

Should it be the latest stable version or include pre-releases?

You need to fetch the latest version from the same source we get the other versions, otherwise the task will fail when there is a new release as it's tagged before the builds are available (at least for elixir and erlang).

Do you have an example of this, and how long would it take to create a release before the builds are available?

https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#get-the-latest-release

The latest release is the most recent non-prerelease, non-draft release, sorted by the created_at attribute. The created_at attribute is the date of the commit used for the release, and not the date when the release was drafted or published.

The latest release does not include pre-releases.

[ericmj]

Do you have an example of this

You can check the builds.txt files we fetch to get the list of versions.

and how long would it take to create a release before the builds are available?

It depends on a lot of factors but normally 10-30min. Sometimes a build fails which requires manual fixing which can take hours to days.

[Schultzer]

You can check the builds.txt files we fetch to get the list of versions.

I've refactored to get the latest semver version from the build.text, which should solve the issue with builds not being available and the test suite passing locally for me.

[paulo-ferraz-oliveira]

Let's say erlang/otp releases 24.2.5, but 24.2.4 is the one set to "latest". Shall a rule in setup-beam override that? Or where will the semantics reside?

[Schultzer]

Let's say erlang/otp releases 24.2.5, but 24.2.4 is the one set to "latest". Shall a rule in setup-beam override that? Or where will the semantics reside?

I realized I had a few bugs, so now I use Semver to resolve the latest Elixir and OTP builds. Furthermore, a bug in Semver prevented prereleases from being parsed, so I've updated the package.

We can leverage Semver to parse that with its right-hand rule to parse OTP release by looking if a tag has otp in it.

I tested this locally by changing the platform clauses from Linux to Darwin and Win32 to Darwin. I'm confident about the changes I committed.

[ericmj]

How does the semver library handle OTP versions that does not follow the semver specification, such as OTP-25.3.2.12?

[Schultzer]

I got lost in this codebase and the review comments; I've opened #269, which is way simpler than I tried to do here.