Caddy 1.0.0 release reports version incorrectly

[predominant]

1. Which version of Caddy are you using (caddy -version)?

Using release 1.0.0

2. What are you trying to do?

Confirm the caddy version:

caddy -version

3. What is your Caddyfile?

N/A

4. How did you run Caddy (give the full command and describe the execution environment)?

caddy -version

5. Please paste any relevant HTTP request(s) here.

N/A

6. What did you expect to see?

v1.0.0

7. What did you see instead (give full error messages and/or log)?

v0.0.0-00010101000000-000000000000

8. Why is this a bug, and how do you think this should be fixed?

Version should at least show v1.0.0 at the start of the version output string.

9. What are you doing to work around the problem in the meantime?

No known workaround.

10. Please link to any related issues, pull requests, and/or discussion.

N/A

Bonus: What do you use Caddy for? Why did you choose Caddy?

N/A

[mholt]

The version is correct when downloaded from the build server, but because of a bit of a weird quirk with Go modules and some ripple effect down the toolchain + my local build environment, the release assets on GitHub do have the version reported incorrectly, it's true.

The root cause of this, I believe, is at golang/go#29228.

[stp-ip]

We could read the version ourselves and not rely on the module version, but I assume this was chosen to keep one true version. One downside with this is that the version can't be overwritten via ldflags, which might come in handy.

Workaround in the linked issue feels hacky, but at least a way to overwrite versioning.

[carlwgeorge]

I also use ldflags to set the version for Fedora's RPM package of Caddy. Having a convenient method to define the version during the build (independent of modules) would be nice to have.

[mholt]

I haven't updated the automated build process I use here to do Caddy releases, and I will be rewriting it for v2, which is just around the corner, so this is unlikely to get fixed, FYI. Sorry.