@haya14busa

Currently the staticcheck repository has a weird naming pattern for releases. Instead of the version they name the release after the day on which it was created. That makes it quite difficult to allow the user to choose the staticcheck version.

However before the refactoring we also always used the latest one, so this is not really a downgrade.
Maybe you've a good idea on how we can improve that.

Currently the staticcheck repository has a weird naming pattern for releases. Instead of the version they name the release after the day on which it was created. That makes it quite difficult to allow the user to choose the staticcheck version.

That is not quite correct. The versioning scheme is <year>.<major>.<patch>. For example, 2020.2.2 was the second patch release for 2020.2, which was the second major release in 2020. These versions are only connected to a date in that major releases are relative to the year they're made in. The next patch release for 2020.2 would be 2020.2.3, and the next feature release will (hopefully) be 2021.1.

@dominikh,

Ah thnx for the insights 👍 .
I will adjust this PR, so that users can overwrite the staticcheck version

@kstiehl Thank you for the great work! LGTM 👍
As for the staticcheck version, this repo used the latest version before as you mentioned, so it's ok to merge this p-r first and work on the version-related work separately.

@dominikh
Thank you for your information! I just want to confirm, but does it mean we can assume the staticcheck version format follows (or is compatible with) the semantic version format?
I'd like to automate managing staticcheck version with the automated workflow (https://github.com/reviewdog/action-depup), and it's compatible with semantic version format and I wonder we can use this for staticcheck.

🚀 [bumpr] Bumped! New version:v1.5.0 Changes:v1.4.3...v1.5.0

I filed #17 for the follow-up :)

Thank you for your information! I just want to confirm, but does it mean we can assume the staticcheck version format follows (or is compatible with) the semantic version format?
I'd like to automate managing staticcheck version with the automated workflow (https://github.com/reviewdog/action-depup), and it's compatible with semantic version format and I wonder we can use this for staticcheck.

Well, not precisely. <year>.<major>.<patch> does not map directly to <major>.<minor>.<patch>. For example Staticcheck 2020.2 may have changes that are not backwards compatible to 2020.1. The versions will always contain 2 or 3 dot-separated elements, but the elements do not have the same meaning as they do in semver.

There is a separate set of tags that exist explicitly to make Go modules happy. These are v0.<minor>.<patch>. 2020.2 is v0.1.0, 2020.2.1 is v0.1.1, 2021.1 will be v0.2.0, and so on. These are truly semver, but only because major version zero carries no guarantees.

In general, it's recommended to always read the release notes of Staticcheck before upgrading to a new version, which precludes fully automatic updates.

Thanks for the clarification! I understand it's not semantically the same as the semver, but as long as the format is <year>.<major>.<patch>, probably we can use action-depup.

In general, it's recommended to always read the release notes of Staticcheck before upgrading to a new version, which precludes fully automatic updates.

Yes! I meant I'd like to automate the update flow, especially for creating a Pull Request (like dependabot/renovate) so that we can notice new releases of staticcheck and make it easy to bump the version. We can check the release note before merging it.