[FEAT] provides changelog

[pinage404]

Is your feature request related to a problem? Please describe. When you publish a new version, it often happens that the packaging breaks

I have to do a kind of retro-engineering to try to determine what has changed and how it can be packaged again

Examples :

• Binary path :
  • In the release 2.1.2, the binary gk was in the root of the archive
  • In the release 3.0.6, the binary was in gk_3.0.6_linux_386/gk
  • In the release 3.1.9, the binary gk is in the root of the archive (like in 2.1.2)
• Shell completions (with Bash as example) :
  • In the release 2.1.2, the shell completions scripts was in completions/gk.bash
  • In the release 3.0.9, the shell completions was generated using gk completion bash
• Platform supported :
  • In the release 2.1.2, Linux ARM v6 & Linux ARM v7 was supported
  • In the release 3.0.0, Linux ARM v6 & Linux ARM v7 has been removed & Windows ARM 64 has been added
• Release URL (Linux Intel as example) :
  • In the release 2.1.2, the URL was gk_2.1.2_Linux_x86_64.zip so gk_<version>_<OsCapitalized>_<architecture>.zip
  • In the release 3.0.0, the URL was gk_3.0.0_linux_amd64.zip so gk_<version>_<oslowercased>_<architecture_but_differently>.zip

Describe the solution you'd like I would like that you provides a changelog that describes what changed since the previous version

Ideally, i would like to have it in the Github Releases or in a CHANGELOG.md file at the root of the repository

It's perfectly fine to change stuffs, but please, helps packagers by explaining what changed

Describe alternatives you've considered Stop maintaining the gk-cli package on nixpkgs

[thenexxuz]

As the maintainer of the AUR package, this would help as well.

[JBUinfo]

Hi! Sorry for the trouble caused by the recent updates. Version 3.0 brought a lot of changes, and since then we’ve been adjusting our deployment process. Our goal is to keep things more stable and we’re also looking into the best way to share changelogs from now on

From this point on, updates will be delivered automatically. The ones you’ll see in this repository or through package managers will mainly affect the launcher, not the core features or fixes. The launcher shouldn't need to be updated often, but as mentioned, we’re still in the middle of some big transitions after 3.0.

About your suggestion to stop maintaining the gk-cli package on nixpkgs, just to clarify, we’re not the official maintainers of that platform, though we do care about any changes that could affect it.

Thanks so much to both @thenexxuz and @pinage404 for your input, we really appreciate your contributions and will definitely keep your proposal in mind!