You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by kxepal <gi...@git.apache.org> on 2014/11/08 15:59:00 UTC
[GitHub] couchdb-couch pull request: Normalize special CouchDB headers name...
GitHub user kxepal opened a pull request:
https://github.com/apache/couchdb-couch/pull/15
Normalize special CouchDB headers names
COUCHDB-2353
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/kxepal/couchdb-couch 2353-normalize-special-headers-names
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/couchdb-couch/pull/15.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #15
----
commit 72e6f34e26cb9ebc6add9feccfe2b9e2226c417e
Author: Alexander Shorin <kx...@apache.org>
Date: 2014-11-08T14:50:44Z
Normalize special CouchDB headers names
COUCHDB-2353
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-couch pull request: Normalize special CouchDB headers name...
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on the pull request:
https://github.com/apache/couchdb-couch/pull/15#issuecomment-62441918
@davisp I found myself more frustrated because special headers are don't follows some single logic and I have always consult myself with docs to be sure that I name it right (since CouchDB will just ignore unknown header).
As for backward compatibility point, it only matters for replicator which uses X-Couch-Full-Commit to force CouchDB accept new docs with delayed_commits on. I believe, this isn't what we want to let him doing, but that's another story.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-couch pull request: Normalize special CouchDB headers name...
Posted by davisp <gi...@git.apache.org>.
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/15#issuecomment-62443228
@kxepal Sure, I agree that normalizing things to be consistent is a good idea. I'm just saying that for any user that happens to miss this particular change in the log will have a very bad experience figuring the change out. If we instead detected the presence of old headers and returned a 400 Bad Request we could inform them directly that the header names have changed. Alternatively we could upgrade old header names though in the interest of deprecating I'd prefer the 400 I think.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-couch pull request: Normalize special CouchDB headers name...
Posted by janl <gi...@git.apache.org>.
Github user janl commented on the pull request:
https://github.com/apache/couchdb-couch/pull/15#issuecomment-62447266
>> Maybe also send an x-couch-deprecation-notice header with an URL to the docs where it is explained.
> We'd already discussed this moment: nobody will look and process this header to be notified about.
Then maybe not :) — I know I’d be looking at it, but that’s not representative.
> break more at once or break by a little for many times
I’ve only seen the latter work satisfactory. But that’s my personal bubble :)
Thanks for getting the discussion rolling!
* * *
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.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-couch pull request: Normalize special CouchDB headers name...
Posted by janl <gi...@git.apache.org>.
Github user janl commented on the pull request:
https://github.com/apache/couchdb-couch/pull/15#issuecomment-62443798
Can we please stop the meme of “we are bumping the major version so let’s break everything.”?
We should be **very** deliberate with what we break and when, in order to avoid a Python 3 situation. From my post on dev@ earlier today on the `delayed_commits` thread:
> One of my goals for CouchDB 2.0 is that people upgrading form 1.0 and
> especially people who continue use CouchDB in a single-node scenario
> have an easy time. Just breaking more things because we happen to be
> bumping a version number is not a good motivation. Especially in our
> new world of avoiding attaching marketing connotation to major release
> versions (except 2.0 :), we can release CouchDB 3.0 and 4.0 shortly
> after 2.0 if it means we break BC in a single way. If we keep BC breaks
> to a minimum and make every transition up a major version as easy as
> possible, we don’t run into a Python 3 situation that creates a major
> schism in the user community that takes a decade to heal.
>
> Let’s not break things because we update the major version number,
> instead, let’s update the major version number whenever we break
> back backward compatibility.
* * *
I do like the idea of detecting the “wrong” case and logging an error so people have a chance to upgrade it. Maybe also send an x-couch-deprecation-notice header with an URL to the docs where it is explained.
* * *
-1 on breaking BC for this without a plan.
(sorry @kxepal :)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-couch pull request: Normalize special CouchDB headers name...
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on the pull request:
https://github.com/apache/couchdb-couch/pull/15#issuecomment-62445659
> Maybe also send an x-couch-deprecation-notice header with an URL to the docs where it is explained.
We'd already discussed this moment: nobody will look and process this header to be notified about.
> Can we please stop the meme of “we are bumping the major version so let’s break everything.”?
Question not about breaking everything in the name of major version bump, but cleanup existed things. What you suggests (`we can release CouchDB 3.0 and 4.0 shortly`) has own drawback side: people wouldn't use our releases because we minory breaking things _too often_ to support any of these versions and they will wait until we stop doing this. So it's about of choice of lesser evil: break more at once or break by a little for many times. I, as a user, agreed to suffer BC releases as far as this would be rare thing no matter how much stuff is broken - until migration process and alternatives will be well documented and will not require a lot of work to maintain compatibility of multiple (or two at least) major releases.
And I just proposed this change to trigger the discussion about how handle it right (: @davisp suggested good idea with 400 response, so users will be alerted about using old stuff for new environment. More ideas are welcome (:
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-couch pull request: Normalize special CouchDB headers name...
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on the pull request:
https://github.com/apache/couchdb-couch/pull/15#issuecomment-62260620
This obliviously breaks backward compatibility, but 2.0 is a good time to cleanup and normalize stuff.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-couch pull request: Normalize special CouchDB headers name...
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on the pull request:
https://github.com/apache/couchdb-couch/pull/15#issuecomment-62448113
> 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
Good idea and well balanced. I like it (: Will rewrite my PR to match it.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-couch pull request: Normalize special CouchDB headers name...
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on the pull request:
https://github.com/apache/couchdb-couch/pull/15#issuecomment-62260599
If the solution is ok, I'll open few more PRs against chttpd, replicator and mrview.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-couch pull request: Normalize special CouchDB headers name...
Posted by davisp <gi...@git.apache.org>.
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/15#issuecomment-62440626
Do we want to worry about backwards compatibility here or not? Or maybe we can add a check that throws a 400 if it detects an old header name? This just feels like one of those places where people will get frustrated when something doesn't work like it used to without any feedback or indication of what exactly changed.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---