> > CDC sounds like it is in the same basket, but it already has the
> > `cdc_enabled` yaml flag which defaults false.
>
> I went this route because I was incredibly wary of changing the CL
> code and wanted to shield non-CDC users from any and all risk I
> reasonably could.
This approach so far is my favourite. (Thanks Josh.)
The flag name `cdc_enabled` is simple and, without adjectives, does not
imply "experimental" or "beta" or anything like that.
It does make life easier for both operators and the C* developers.
I'm also fond of how Apache projects often vote both on the release as well
as its stability flag: Alpha|Beta|GA (General Availability).
https://httpd.apache.org/dev/release.html
http://www.apache.org/legal/release-policy.html#release-types
Given the importance of The Database, i'd be keen to see attached such
community-agreed quality references. And going further, not just to the
releases but also to substantial new features (those yet to reach GA). Then
the downloads page could provide a table something like
https://paste.apache.org/FzrQ
It's just one idea to throw out there, and while it hijacks the thread a
bit, it could even with just the quality tag on releases go a long way with
user trust. Especially if we really are humble about it and use GA
appropriately. For example I'm perfectly happy using a beta in production
if I see the community otherwise has good processes in place and there's
strong testing and staging resources to take advantage of. And as Kurt has
implied many users are indeed smart and wise enough to know how to safely
test and cautiously use even alpha features in production.
Anyway, with or without the above idea, yaml flag names that don't
use adjectives could address Kurt's concerns about pulling the rug from
under the feet of existing users. Such a flag is but a small improvement
suitable for a minor release (you must read the NEWS.txt before even a
patch upgrade), and the documentation is only making explicit what should
have been all along. Users shouldn't feel that we're returning features
into "alpha|beta" mode when what we're actually doing is improving the
community's quality assurance documentation.
Mick
