Branch swap: Move master to v1, and v2 to master

[mholt]

This is just an informational bulletin for anyone who is maintaining cloned versions of this repository on their local machine.

In the next week (maybe even next day or two), I will be switching branches around:

• master -> v1
• v2 -> master

In preparation for the release candidates of Caddy 2.

If you're actively maintaining a local clone of the repo, you may want to re-clone after this change is complete.

We're just renaming the trees. Renaming locally is easy. To rename on the server, the branch is deleted then recreated with the new name. I've tested this process in copies of this repo and confirmed that it will only take a few minutes. There is a brief window where master will not be available, but it should last just a few seconds/minutes. No commits or history will be lost.

The master branch has 5+ years of history, which is cool, until you want to clone the repo for a quick thing. Because we vendored dependencies for a couple years, the master branch has a lot of bloat in it. (And not everyone does a shallow clone, and those are kinda hard under some circumstances anyway.) We vendored in order to pin versions, but now Go modules do that for us, without adding hundreds of MB of bloat.

(I am not particularly interested in the other reasons for vendoring right now, such as code availability, etc etc -- vendoring introduced bugs into Caddy and I'd like to avoid it, plus, the modules are cached in numerous places so even if the source goes down, it can still be retrieved.)

Anyway, v1 will eventually be deprecated. Version 2 started from a totally different code base because I rewrote Caddy completely from scratch. Keeping them on separate branches will make the short-term maintenance of v1 (security patches, etc.) and eventual archival much easier.

I don't expect any disruption with regards to tags or Go module versioning because we've been using tags, and pulling from branches named "v2" doesn't work with Go modules, either (le sigh). By not using a branch named "vN" (for N > 1) we can evade that bug.

This change also has the benefit of making the version 2 code base the default across the board (and not just on GitHub, where yes, you can change the default branch), speeds up clone times, and allows us to focus on v2 as the new standard default going forward. We won't have to indicate that things are for 'v2' (it'll be assumed).

[42wim]

If you tag it v2.0.0 on a master branch, it'll only work when people do go get github.com/caddyserver/caddy@latest and this will show a v1.0.6-xxxx-gitcommit in the go.mod instead of v2.0.0 (if v1.0.5 is your last 1.0.x tag)

go get -u github.com/caddyserver/caddy will not update locally to any tags beyond v1.x

[mholt]

That has nothing to do with the branch though. That's due to Go modules' semantic import versioning.

github.com/caddyserver/caddy is for v1 or lower.

githib.com/caddyserver/caddy/v2 is the module name for all v2 code, regardless of the branch it lives on. To go, they are totally separate modules.

That's just how it is.

[42wim]

@mholt: sorry for adding confusion about this, you're right it'll work fine. (I had tested without a /v2 in the go.mod)

[mholt]

No problem :)

[mholt]

Swap completed.