Caddy 2.4.0 beta 1 is now available

Announcements
21

The backup occurs, but is cleaned up after the change finishes successfully.

22

Sure, but only if that brings you from like v2.3.0-beta.1 to v2.3.0 for example. Going from a v2.4.0-beta.1 to v2.3.0 doesn’t make sense IMO. That’s clearly a downgrade.

23

I’d even go so far as to say that going from 2.3.0-beta-1 to 2.3.0 isn’t an upgrade, it’s a channel swap. It might be practically an upgrade because it’s strictly newer, more updated code. But as we can see if we channel swap from beta to stable and go backwards in semantic version, that’s definitely not newer code. Conceptually the difference is important, I think.

Strictly speaking an upgrade would be 2.3.0-beta.1 to hypothetically 2.3.0-beta.2 or 2.4.0-beta.1.

1 Like
24

I see the dilemma here, though I’m not sure that latest stable is the right terminology to use; maybe
latest release or latest official is a better choice of words. My reasoning is, the Caddy reverse proxy that drives my production environment is predicated on an xcaddy build master. This was necessary to solve the map directive issue identified in the thread Migrate to using a wildcard certificate. In that thread, I even expressed concern about moving away from Caddy 2.3.0 to the beta, but I had to make a choice. I chose the beta and it solved the issue and had no other visible impact on the production environment. IMO, that’s the latest stable version of Caddy even if it’s not deemed the latest official version.

I wonder if a way around this may be to allow both behaviours? For example, caddy upgrade for the existing behaviour and caddy upgrade -master to allow the latest tweaks from the master to filter through.

I wonder if there’s any harm in leaving the backup there (instead of naming it caddy.tmp, it could be named caddy.backup), but overwriting it when Caddy is next upgraded? This provides an easy path to revert back to the last release prior to the upgrade if required. It would have been useful in this instance i.e. to revert back to the 2.4.0-beta.1 from 2.3.0.

25

I don’t think I agree. You wouldn’t want to skip v2.3.0 if you were on v2.3.0-beta.1, that doesn’t make sense. We don’t tend have a beta for the next version before we have stable for the previous. If we wanted to introduce channels as a concept then we’d need to allow the user to separately indicate what channel they want to be in. We do have that for the apt repos Install — Caddy Documentation where we have two separate repos, one stable and one testing.

1 Like
26

A fair disagreement, to be sure.

Either way I don’t think there’s any scenario where it makes sense to call a 2.4.0 beta reverting to 2.3.0 stable to be a functional upgrade. An argument could be made that you could colloquially refer to it as a stability upgrade, but not in terms of software functionality would it ever be called an upgrade.

3 Likes
27

Maybe it’s a bit like negative growth, a popular term among economists :wink:

28

Just want to open up a discussion around caddy fmt. According to the 2.4.0 release notes:

  • Caddyfile fmt lint check. When running with a Caddyfile, Caddy will emit a warning if the Caddyfile is not formatted with caddy fmt.

WARNING

When I reload my Caddyfile, this is the output I see:

# service caddy reload
2021/03/22 05:10:55.234 INFO    using provided configuration    {"config_file": "/usr/local/www/Caddyfile", "config_adapter": "caddyfile"}
[WARNING][caddyfile] /usr/local/www/Caddyfile:2: input is not formatted with 'caddy fmt'

Is caddy fmt a mandatory or non-mandatory step? If it’s optional, does it need to be a WARNING? If not, can I suggest that the bracketed word [WARNING] be changed to [INFO]? Personally, at present, I find the message comes across like a red flag.

caddy fmt options

This is the current list of fmt options:

# caddy fmt --help
Usage of format:
  -overwrite
        Overwrite the input file with the results

caddy fmt does a good job of formatting the Caddyfile. The indentation is eight spaces. I already indent (using two spaces). I’d be more inclined to use caddy fmt if I had a choice over the depth of indentation. I’m not sure how other forum members feel about this?

caddy fmt sometimes does too good a job at formatting… for a machine. At times, it misses the human element. There are some areas of the Caddyfile that I prefer not to be formatted, for example, around the map directive.

Before formatting…

  map {path} {backend} {online} {

#   PATH                BACKEND          ONLINE
#---------------------------------------------------------------
    ~^/tautulli.*       10.1.1.26:8181   yes
    ~^/transmission.*   10.1.1.28:9091   yes
    ~^/.*               10.1.1.55:80     yes
  }

After formatting…

        map {path} {backend} {online} {
                #   PATH                BACKEND          ONLINE
                #---------------------------------------------------------------
                ~^/tautulli.* 10.1.1.26:8181 yes
                ~^/transmission.* 10.1.1.28:9091 yes
                ~^/.* 10.1.1.55:80 yes
        }

Unless you’re Cypher and can read The Matrix, I know which version I prefer.

29

In this case, all Caddyfile adapter warnings are basically “non-errors”, as in things that don’t need to prevent Caddy from running. There’s no concept of log levels for those, although it may seem like it. I understand what you mean though.

Somewhat related, you reminded me that the fmt log is using fmt.Printf instead of the zap logger, so it sticks out like a sore thumb. PR to fix:

2 Likes
30

This topic was automatically closed after 120 days. New replies are no longer allowed.