I also like the idea of deprecating that feature in 2.0, and removing it in 3.0.
Here's a list of places where we probably want to place our deprecation warning (please tell me if anything is missing): * release notes * documentation * configuration files (default.ini etc.) * log file(s) (only when the feature's enabled) Cheers, Klaus On 10.11.2014 21:30, Alexander Shorin wrote: > Jan made a great proposal on > https://github.com/apache/couchdb-couch/pull/15#issuecomment-62447266 > > On Mon, Nov 10, 2014 at 11:15 PM, janl <g...@git.apache.org> wrote: >> I think at some point we generally agreed on this process: >> >> 1. Version N: Has feature X >> 2. Version N+1: Feature X gets a deprecation warning (release notes, >> logs etc.) / handles the new and old case gracefully (if possible) >> 3. Version N+2: Feature X gets removed >> >> So in this case, I’d say: >> >> 1. CouchDB 1.0 has this feature >> 2. CouchDB 2.0: >> - accepts both the fixed and the existing notations (like we did with >> the `authentification` config value or header, I forget) >> - prints warning (say in the logs), when the old notation is used >> - release notes carry deprecation warning >> 3. CouchDB 3.0 sends 400 error on the old notation and just works on the >> new one. The change is made. > > I like it since it not break things instantly, but allows to handle > both old and new clients, makes migration more smooth and gives a lot > of time to update old code. > > Adapting Jan's proposal onto removing delayed_commits, it could be looks as: > 1. CouchDB 1.0: delayed_commits = true > 2.a CouchDB 2.0: delayed_commits = false, sets explicitly in default.ini > 2.b CouchDB 2.0: delayed_commits = false , sets implicitly in code > defaults, default.ini doesn't contains it > 3. CouchDB 3.0: delayed_commits = false permanently, config option > gets ignored if present. > > -- > ,,,^..^,,, >
signature.asc
Description: OpenPGP digital signature
