Open basilhendroff opened 3 years ago
I'm guessing that the currently installed version is not checked in https://github.com/caddyserver/caddy/blob/f6bb02b303d4a24c6932fd832f7aa9de224b6833/cmd/commandfuncs.go#L582 and thus it just downloads the stable and installs it?
@xdevs23 Correct. The problem I'm currently wrestling with is, I'm not sure how to know what the new version will be before Go builds it. Without an explicit version passed into the go
command, it uses latest
which is kind of mysterious. We could just go ahead with the upgrade anyway and then check its resulting version string by running caddy version
on the new binary, but this is not ideal if the resulting binary isn't even wanted in the first place; it adds pressure to the Caddy build server and takes time, etc.
As for:
Backup file caddy.tmp is not created
This is not actually the case, as discussed in the thread; it just gets cleaned up afterward after a successful upgrade. We can consider leaving it though.
Would it be possible to have an API endpoint (or maybe just a file in each GitHub release) containing its own version? For example:
https://github.com/caddyserver/caddy/releases/download/latest/version.txt
And then just parse the semver and check if it's newer (and not a version that has an extra string at the end like -beta.1
)
This could be incorporated into the cmdUpgrade function so that checking for a new version is just a simple GET call with a text response.
Someone showed me how to get the version that the go
tool will resolve to, like which version will be used when latest
is specified:
$ go list -m -json github.com/caddyserver/caddy/v2@latest
@mholt apparently this could work too (note the >
):
$ go list -m -json github.com/caddyserver/caddy/v2@>{current_version}
e.g.
$ go list -m -json github.com/caddyserver/caddy/v2@>v2.4.0-beta.1
But unfortunately I don't think we can actually test this right now because the latest version happens to be a stable version, since we just released v2.4.0
🤦♂️
I stumbled into this issue and accidentally opened duplicate issue #4159
Another thing to think about is whether a plugin update should ideally trigger an upgrade. I don't know how any of this is managed on the back-end but, if Caddy isn't updated and one of the requested plugins has an update, should this trigger an upgrade?
Would this be more easily solved with an upgrade web service? I'm imagining something like:
upgrade
is called, Caddy sends its version as well as all plugin versions to the upgrade web service.I always run caddy upgrade
before actually starting Caddy to keep my install up-to-date and I would like to see a version check before upgrading as well, so Caddy won't upgrade itself (and download the binary) on every run even when it already is on the latest version.
Two issues:
For details, please refer to https://caddy.community/t/caddy-2-4-0-beta-1-is-now-available/11519/17?u=basil