We’ve pegged caddy to v0.10.11 for ci purposes, using drone/docker images. Recently we had need to rebuild the ci container and caddy no longer builds because the caddyserver/builds repo has been deleted/privatized. We can always update to a newer caddy, but breaking old builds should be avoided as much as possible for debugging/bisecting/historical analysis purposes.
Can you bring back github.com/caddyserver/builds as an archived repository?
Will continue discussion in the issue – but FWIW I’m not particularly interested in maintaining that repo for an old function that is no longer needed. I highly recommend upgrading your systems to use newer versions of Caddy!
But to hold you over, here is the function as a gist, which I may still get rid of after a while: Build helper for Caddy <= v0.11.5 · GitHub
I’m keeping the repo private for now and will delete it soon, to verify that all dependencies on it are eliminated.
I understand not wanting to maintain that repo, but this is not that case. You’re intentionally breaking things ala whats been seen in the js world (left pad…) and things going away. This is always a danger that can happen and users need to take account of, but in this case I don’t see the reason for not leaving it as an “archived” (read only) repo?
Its not just about my use case of building an older caddy for ci purposes, I can always upgrade as you say (tried that, but master broke too. I went back and just used go build). But wanting to inspect/build previous versions for debugging/comparison has no recourse if the goal is “build as if I had a time machine”. With caddyserver/builds gone forever there isn’t really a very good option.
There’s no real incentive for me to maintain that little repo. Besides, it’d just be making it easier to use older and older Caddy versions, which is not a good idea.
If you’re referring to your attempts in the issue, it’s because you didn’t actually try building from master.
I linked you to the source code – the whole repo is 1 function. That is the benefit of open source. 
However, we’ll be happy to accommodate keeping the repository available for you if you have a support contract! Let me know if you’re interested, we can definitely support your business with what it needs.
There would be no maintenance, github automagically has a “repo is archived” banner that makes it obvious to all that nothing is going to change about this repo.
It also makes it harder to study caddy <1.0 source and behavior by making each and every person hunt down how to build caddy <1.0 in post 1.0 world forever and ever.
I understand the beauty of open source, but this move to make caddyserver/builds go away is anti-community (and also why GPL style licenses make build scripts part of the required source package, though doesn’t apply here).
–
Anyway, I’m not sure I’ll be able to change your opinion. I’m very much happy to update my caddy (or do the plain go build work around). I wanted to express that the removal of caddyserver/builds makes software archaeology harder and goes against “never break the build”, “keep master green”, software reproducibility and git bisect-ability and co. I think you are focused on moving/looking forward and I’m interested in history not being made stale/obsolete/worth-less. (side note: I love living on the edge, I’ll happily run master or .0s or w/e, but I prefer updates to be on my terms/timeline.)
Personally, I have no problems with moving to Caddy 1.0.0. However, bare in mind the opposite outcome may happen too as result - forcing users to stay on even older releases for a longer duration as they can’t get to 0.11.5 at least when they aren’t ready for 1.0.0+ yet.
So not sure which is worse a Caddy 0.11.0 or older user stuck on outdated 0.11.0 or older much longer than needed and wanting to update to 0.11.5 but can’t (easily) and isn’t ready for Caddy 1.0.0 versus Caddy 0.11.5 user not moving to Caddy 1.0.0 right this moment?
Seriously, Caddy < 1.0 can be built with go get, go install, go build, etc. It just won’t have version information with caddy -version. Not a big deal.
That file is not as important as you’re making it. I guarantee it!