5 ms·
I think I'd disagree. While Caddy doesn't do that, production readiness is something that can be objectively measured. Define some metric, like "how many % use
by drdaeman 10y ago
I think I'd disagree.
While Caddy doesn't do that, production readiness is something that can be objectively measured. Define some metric, like "how many % users encounter stability-related issues/error conditions", throw in telemetry and there will be solid numbers. Many do that with their own software deployments, using Sentry or similar solutions, deciding on whenever their beta deployments are "production ready" or "not yet". Of course, that only works with a large enough user base, otherwise the error margins are too high for the number to be any meaningful. It is relative only in regard whenever, say, "0.01% (just a random number) of users have encountered severe issues" is "way too many" or "oh, it's just a few".
Security, on the other hand, is a different beast. Formal proofs aside - trying to define some similar metric "how many installations were hacked" or "how many security issues were found" isn't really meaningful.
But I think it would be really off-topic. =/
- omginternets 10y agoYou're missing my point, I think. What you're describing is an epistemological problem, i.e.: "how do I know this thing is production ready?". This problem is (mostly) independent of whether or not the thing actually is production-ready. The point is that knowing about previous use in production is one way of knowing to what extent something is production-ready. There are other ways (e.g.: well-controlled tests). As for your point about security, I couldn't disagree more strongly. Comparing histories of compromises and mitigations across various projects is, in practice, a very useful metric. See OpenBSD for an example.