I was also extremely confused by the naming and still do not understand why FreeBSD is sticking with it, unless FreeBSD developers want to emphasize the system is created for developers, but not end users.
This would only be true if you insinuate only developers would ever read documentation.
The term "release" is well-known and certainly doesn't require special knowledge. So once you look for available downloads, see -RELEASE versions first and recommended
and then, you see there's also -STABLE, how in the world would you ever conclude to just install that? If you really
think "wait, isn't that the same?", wouldn't you just read the few sentences on FreeBSD pages that explain how it's a version under development?
BTW, at work, we adopted a similar branching scheme (main/stable/release) for an internally shared project, because this works really well. We did one little naming change though: "stable-api" instead of "stable", to avoid this little confusion for people who don't read the docs first
. Still, the word "stable" is extremely important here. This scheme is working so well because
APIs/ABI don't change on that branch, which guarantees seamless minor upgrades and simple merging of security fixes to the release branches.
End users expect something called "stable" to be stable, maybe with long-term support, but definitely production-ready.
And about this, what's "production-ready" is ultimately up to you to decide. A classic release engineering can guarantee the best quality, so that's recommended for production. Still, stable is
"stable". Only compatible changes (read: no breaking changes) are ever merged to stable, and only after some testing period on main (-CURRENT). So, if
you'd ever consider e.g. some rolling-release Linux dist (where the base components are continuously updated as well, and don't even care for breaking changes) "production-ready", FreeBSD -STABLE is as well.