couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From janl <...@git.apache.org>
Subject [GitHub] couchdb-couch pull request: Normalize special CouchDB headers name...
Date Mon, 10 Nov 2014 19:53:46 GMT
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.
---

Mime
View raw message