Look into goreleaser/automatic release in GH-CI

Hello @mstruebing !

I was looking into the repo last weekend coming from a discussion from MegaLinter, and understood that this was quite a blocker and could really help. So I read about GoReleaser and it seemed very awesome! I planned to work on it on free time the following weekend.

So to make things short, this afternoon I played a bit with GoReleaser on my fork, (my first time with Go at the same time), but I had to stop before finishing. I just committed where I was at when I stopped. https://github.com/echoix/editorconfig-checker/tree/dev/goreleaser

So I wanted to discuss some little points. I want to create a PR that addresses only one thing, but it's really really easy to just fix some issues at the same time, instead of working to reimplement them and after that fixing them. So, what is the approach that you would prefer: (1) Configure GoReleaser as I think that seems like a generally accepted standard way, ie: to the best of my knowledge, OR, (2) try to mimic exactly the same release process mechanism as currently implemented, including the flaws that some are reported in issues in this repo.

• At what point does your user base rely on exactly the same packaging format?

By default, GoReleaser would set the name of the executable to "editorconfig-checker", thus the executable inside the releases would be called this unique name. If I keep that, this would fix #232 (and #208) and I see that there was some activity today, and the discussion seems to tend towards this.

Then, I think it's better to have Windows releases in zip format, since there is no .tar.gz support natively, I use 7zip for that.

Without any workarounds, the default output obtained by using GoReleaser also doesn't seem affected by #229, but I see now that it was fixed today :)

Next set of questions:

• I see that you release for a whole lot of platforms, but are you able to use it on all of them, or it's just because Go is able to compile for that platform? I seriously never heard of AIX nor illumos. I'm not even asking if we test it on them, only if it can really be used.
• GoReleaser is able to generate Docker images. Would you want me to integrate it at the same time? I saw that #219 was closed today also, but it was only pushed with the tag 2.7.0, without adding latest. I didn't get at that point in the docs yet, so I didn't configure it, but I would like to take a look at it, and create/adjust a dedicated GitHub workflow for it if it doesn't work natively out of the box.
• In the output formats, it's possible to create some Linux distro-specific releases too. Are you interested in that too? I don't think there's really an inconvenience doing it. Maybe it could help out for #200, and it can also create a snap package, (if anyone really likes snap packages anyways)
• macOS binaries: it's possible to create universal binaries for macOS, that is, it includes both the amd64 and arm64 in a same binary. I think it's a good idea, even if the size of the file is a little bigger.
• I'm not quite finished exploring the possibilities, but when comes time to prepare the PR, should I work as if it was a version 2.7.1, 2.8.0, or the changes are substantial and it should be like 3.0.0? On second thought, it might be safer to say it's version 3.0.0, since if a build system change affects something that we didn't foresee, we could stand behind the SemVer naming convention that a major release is breaking changes.

Hey, many thanks for your work and time, I appreciate that!

To answer your questions:

I think it would be great to fix some issues a long the way, especially the binary name issue would be really great to do (or as you've pointed out, you do not need to do anything).

I see that you release for a whole lot of platforms, but are you able to use it on all of them, or it's just because Go is able to compile for that platform? I seriously never heard of AIX nor illumos. I'm not even asking if we test it on them, only if it can really be used.

It was just because Go was able to compile it for these platforms and I didn't know which ones will be used, I'm fine with restricting it to a subset.

GoReleaser is able to generate Docker images. Would you want me to integrate it at the same time? I saw that https://github.com/editorconfig-checker/editorconfig-checker/issues/219 was closed today also, but it was only pushed with the tag 2.7.0, without adding latest. I didn't get at that point in the docs yet, so I didn't configure it, but I would like to take a look at it, and create/adjust a dedicated GitHub workflow for it if it doesn't work natively out of the box.

If Gorelease is capable of doing it, we should use it instead of a different solution for releasing docker images in my opinion. I released the docker tag manually (hopefully the last time), that's probably why you didn't see latest.

In the output formats, it's possible to create some Linux distro-specific releases too. Are you interested in that too? I don't think there's really an inconvenience doing it. Maybe it could help out for https://github.com/editorconfig-checker/editorconfig-checker/issues/200, and it can also create a snap package, (if anyone really likes snap packages anyways)

Different solutions for different operating systems would be fine but I do not know how much effort that really is/how it works. I'm only familiar with the Arch User Repository.

macOS binaries: it's possible to create universal binaries for macOS, that is, it includes both the amd64 and arm64 in a same binary. I think it's a good idea, even if the size of the file is a little bigger.

That sounds great but would mean we would need to implement some special logic for MacOs in the wrappers (js, PHP, pyhton) as they pick the binaries they use by operating system and architecture: i.e. https://github.com/editorconfig-checker/editorconfig-checker.javascript/blob/master/src/release.ts#L40-L52

I'm not sure I like that and I think I would prefer to have different binaries for MacOS amd64 and arm64 (or maybe both? But that sounds like overkill).

I'm not quite finished exploring the possibilities, but when comes time to prepare the PR, should I work as if it was a version 2.7.1, 2.8.0, or the changes are substantial and it should be like 3.0.0? On second thought, it might be safer to say it's version 3.0.0, since if a build system change affects something that we didn't foresee, we could stand behind the SemVer naming convention that a major release is breaking changes.

If we change the binary names, we could consider it a breaking change as our wrappers are loading and executing these binaries by their name.

Ok, let's start with this, I'll keep you updated

I think I'll need some Go help soon.

I understood why the releases of editorconfig-checker weren't displayed correctly on https://pkg.go.dev/github.com/editorconfig-checker/editorconfig-checker . I read a lot and learned that when using go, "semantic versioning" (the go way), the format of the tags are important, and it's assumed that the "real" semantic version format contains a v before the tag. Since the tags in the repo never used the v before the version, go, as an ecosystem, never really understood the repo.

Then, I also read that there is a special handling to be done when changing from v1 to v2. Something to do with the namespace. But I didn't really understand it, neither the implications. Since for go, we are really still on v0, which has different conventions, I'm not sure how to properly handle a v3 transition.