Add tags for versions according to required Caddy version
anguzo opened this issue · 4 comments
Since building Caddy with plugins requires the right version of plugin it would be nice if some versions of this module would be tagged for more convenient build.
For example instead of:
--with github.com/mholt/caddy-l4@38bd801
it would be:
--with github.com/mholt/caddy-l4@v2.6.4
It would actually be good if all Caddy plugins followed this approach.
It doesn't make sense to version this module against caddy's versions because there isn't a hard dependency on a specific Caddy version. The dependency listed in go.mod typically points at the minimum version necessary for a module, but not the absolutely required version. Ideally a module specifying a lower version should work with a higher version if the dependency is within the same major version. For example, if the go.mod file lists caddy v2.5.0 as dependency, you could build the module with Caddy v2.6.4 and should build fine.
Life isn't perfect, and breakage occurs, which is why we'd have to increase the minimum version listed in go.mod. Plus, dependabot is ridiculous and doesn't understand these semantics.
You probably just need tags for this module rather than tagging it the same tag as caddy. That we can probably do, especially after resolving a few of the raised issues/PRs.
If you want to build this module with latest Caddy, do:
xcaddy build v2.6.4 --with github.com/mholt/caddy-l4
@mohammed90
Your suggested build command does not work since:
41.74 go: github.com/mholt/caddy-l4@upgrade (v0.0.0-20230809152347-4e8aaac46581) requires github.com/caddyserver/caddy/v2@v2.7.3, not github.com/caddyserver/caddy/v2@v2.6.4
Without using @ syntax it defaults to the main branch if there are no tags which uses version 2.7.3 now making it incompatible with 2.6.4.
I had the same confusion in the past with acme-dns since without @ syntax it defaulted to v0.2.0 tag which was incompatible with 2.6.3 not main branch, so I had to do:
--with github.com/caddy-dns/acmedns@main
I understand that this plugin is in development and there might be breaking changes.
Still I think it would beneficial to newer users of Caddy like myself if those confusions could be avoided with all plugins, not this specific one. Also because searching for the last commit SHA compatible with older version of Caddy is inconvenient.
That happens for me too.
I realize the inability to build with old Caddy versions may be frustrating, but this plugin is fairly tightly coupled with Caddy's exported API so it's best to use the latest Caddy version (even then, it's always a good idea to use the latest stable Caddy version).
As for the tagging proposal, that's something we won't be doing, for multiple reasons discussed here: caddy-dns/cloudflare#58
Thanks for understanding!
Without using @ syntax it defaults to the main branch if there are no tags which uses version 2.7.3 now making it incompatible with 2.6.4.
Sorry, I was typing in a hurry. I meant to use the latest Caddy tag, v2.7.4. The point is, you can still build the latest Caddy regardless of the tag of this module, unless the module depends on a caddy version that's higher than the latest Caddy (e.g. HEAD). We're at the mercy of the Go compiler and module resolution rules.