Some of you have noticed that building Caddy from source (or from the download page!) has been a little difficult lately.
The good news is: building Caddy yourself from source is now much better! It no longer requires using a special build script. And adding plugins no longer requires modifying Caddy’s source code.
We’re transitioning to using Go modules, which is an official dependency management system built into the
go tool. They have some really nice features, but a lot of rough edges too, that have made the transition difficult for me and for many of you. But, in the long run, they will offer stable, secure dependency management that will make development and deployment easier and safer.
If you build Caddy from source, please see the updated instructions linked to in the README and wiki pages above. Note that the instructions will change slightly after we tag the stable 1.0 release, and again after Go 1.13 is released. Both the Caddy and Go projects are very much in a transition period right now.
If you use our download page or getcaddy.com, be aware that many builds may fail, especially those with plugins. There is not a need to report failed builds/downloads at this time.
The reason many builds fail from our download page is because most plugins do not yet use Go modules, and even if they do, they must require one of the recent beta releases of Caddy. This is because all Caddy plugins depend on Caddy. By default, the Go tool uses the latest non-prerelease version when no version is specified (as is the case for all plugins that are not modules, or for modules that do not explicitly pin a specific version). The latest non-prerelelase version of Caddy is
v0.11.5, which does not support Go modules. Thus, it lacks version pinning for its dependencies, some of which have since made incompatible changes. Our
vendor folder used to take care of this problem, but we removed the vendor folder since we want to lighten the repo, and modules does the version pinning for us… or at least, it will after the transition. When we tag
v1.0.0, modules should resolve that version instead and most builds will begin succeeding. But we won’t be sure until that release! So it’s a chicken-and-egg problem.
In the meantime, remember that Caddy 1.0 will not be a perfect release; not all open bugs will have been fixed, etc. We’re merely demarcating where backwards-incompatible changes will no longer intentionally happen on the same major version tree, and celebrating Caddy’s maturity as a web server.