Add semantic versioning tags for Go modules support

[robyngit]

I’m using the wonderful hugo-book for developer docs and I noticed that the current tags (e.g., v10, v9, v8) are not recognized as valid versions by Go Modules.

Go Modules require tags to follow semantic versioning (e.g., v10.0.0, v9.0.0 instead of v10, v9). Without proper semantic versioning, Go falls back to pseudo-versioning and cannot resolve the latest releases cleanly. This forces users to rely on commit hashes or pseudo-versions, which can be cumbersome and less intuitive.

Here are a few ways you can see this issue in action:

1. run go list -m -versions github.com/alex-shpak/hugo-book to see the available versions. The only "version" listed is github.com/alex-shpak/hugo-book itself, rather than the 10 existing tags.
2. run go get github.com/alex-shpak/hugo-book@v10 to fetch the latest v10 release. This command will fail with the error go: github.com/alex-shpak/hugo-book@v10: no matching versions for query "v10".
3. Upgrade hugo-book in a hugo site with hugo mod get -u. The latest commit is fetched instead of the latest release. (Not ideal if those commits are not stable).

Would it be possible to add new tags following the proper SemVer format? For example:

• v10 → v10.0.0
• v9 → v9.0.0

The current tags don’t need to be removed. It's possible to add new tags alongside the existing ones.

This small change would allow Go Modules to resolve the latest releases correctly and would make it easier for tools like Dependabot to track update module dependencies.

Thank you for all of your work on this theme! 🙏

[robyngit]

I can't make a PR to fix this since PRs can't include tags. However, here is what one would need to do to add the new tags:

# Create proper semantic versioning tags
git tag -a v10.0.0 e104a11 -m "Release v10.0.0"
git tag -a v9.0.0 9e9c7d3 -m "Release v9.0.0"
git tag -a v8.0.0 615400b -m "Release v8.0.0"
git tag -a v7.0.0 61b13ba -m "Release v7.0.0"
git tag -a v6.0.0 4e03ee5 -m "Release v6.0.0"
git tag -a v5.0.0 995c1e6 -m "Release v5.0.0"
git tag -a v4.0.0 179d444 -m "Release v4.0.0"
git tag -a v3.0.0 b95fbf9 -m "Release v3.0.0"
git tag -a v2.0.0 cb04554 -m "Release v2.0.0"
git tag -a v1.0.0 4eae7c3 -m "Release v1.0.0"

# Push the new properly formatted tags to GitHub
git push origin v10.0.0 v9.0.0 v8.0.0 v7.0.0 v6.0.0 v5.0.0 v4.0.0 v3.0.0 v2.0.0 v1.0.0

or if you'd prefer to consider the current releases as minor versions of major version 0, you could use the following:

# Create proper semantic versioning tags
git tag -a v0.10.0 e104a11 -m "Release v0.10.0"
git tag -a v0.9.0 9e9c7d3 -m "Release v0.9.0"
git tag -a v0.8.0 615400b -m "Release v0.8.0"
git tag -a v0.7.0 61b13ba -m "Release v0.7.0"
git tag -a v0.6.0 4e03ee5 -m "Release v0.6.0"
git tag -a v0.5.0 995c1e6 -m "Release v0.5.0"
git tag -a v0.4.0 179d444 -m "Release v0.4.0"
git tag -a v0.3.0 b95fbf9 -m "Release v0.3.0"
git tag -a v0.2.0 cb04554 -m "Release v0.2.0"
git tag -a v0.1.0 4eae7c3 -m "Release v0.1.0"

# Push the new properly formatted tags to GitHub
git push origin v0.10.0 v0.9.0 v0.8.0 v0.7.0 v0.6.0 v0.5.0 v0.4.0 v0.3.0 v0.2.0 v0.1.0

[alex-shpak]

Hi! Thank you for suggestion, I go used to clone as submodule, so didn't think much about it.
Not sure I want to go back and update version in history, but I can release semver compatible version next time.