Edit history

Problem

Currently, when a new Fluxer Desktop Client is built, GitHub CI/CD just creates the artifacts and uploads them to the S3 bucket where they are then served as the new version from the fluxer.app website. While this is fine for first party distribution, this creates two problems that I know of:

1. It is difficult for a user to know what commit the desktop client version they are running is based on. I think one could potentially look through github actions to sort of reverse engineer this based on timing, but there should be a more straightforward way to determine this.
2. 3rd party packagers have a difficult time knowing what version of the source code to base their builds off of.

Note: while there is a source tarball uploaded to the S3 bucket as part of the upload in CI, some package maintainers like Terra will refuse to use this.

Proposal

I'm not a developer so I don't know what exactly would be the best approach. From what I understand though, having some way to track releases would be beneficial. This could probably be done through any of the following means:

• Git Tags
• GitHub Releases
• A JSON or API endpoint on the fluxer website that gives the corresponding commit hash to a given version number.

Problem

Currently, when a new Fluxer Desktop Client is built, GitHub CI/CD just creates the artifacts and uploads them to the S3 bucket where they are then served as the new version from the fluxer.app website. While this is fine for first party distribution, this creates two problems that I know of:

1. It is difficult for a user to know what commit the desktop client version they are running is based on. I think one could potentially look through github actions to sort of reverse engineer this based on timing, but there should be a more straightforward way to determine this.
2. 3rd party packagers have a difficult time knowing what version of the source code to base their builds off of.

Note: while there is a source tarball uploaded to the S3 bucket as part of the upload in CI, some package maintainers like Terra will refuse to use this.

Proposal

I'm not a developer so I don't know what exactly would be the best approach. From what I understand though, having some way to track releases would be beneficial. This could probably be done through any of the following means:

• Git Tags
• GitHub Releases
• A JSON or API endpoint on the fluxer website that gives the corresponding commit hash to a given version number.

Notes

No response

Checks

• ☑ I searched existing discussions.

Problem

Currently, when a new Fluxer Desktop Client is built, GitHub CI/CD just creates the artifacts and uploads them to the S3 bucket where they are then served as the new version from the fluxer.app website. While this is fine for first party distribution, this creates two problems that I know of:

1. It is difficult for a user to know what commit the desktop client version they are running is based on. I think one could potentially look through github actions to sort of reverse engineer this based on timing, but there should be a more straightforward way to determine this.
2. 3rd party packagers have a difficult time knowing what version of the source code to base their builds off of.

Note: while there is a source tarball uploaded to the S3 bucket as part of the upload in CI, some package maintainers like Terra will refuse to use this.

Proposal

I'm not a developer so I don't know what exactly would be the best approach. From what I understand though, having some way to track releases would be beneficial. This could probably be done through any of the following means:

• Git Tags
• GitHub Releases
• A JSON or API endpoint on the fluxer website that gives the corresponding commit hash to a given version number.

Notes

No response

Checks

• ☑ I searched existing discussions.