Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of kxepal@gmail.com designates
 209.85.212.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABvT1DGqYiUS64expuorEegc8TSTSqKn+VEcbs3=qzOtmS_-sw@mail.gmail.com>
References: <20131127095756.744979198FD@tyr.zones.apache.org>
	<etPan.5295c58c.12200854.103@Garren-Smiths-MacBook-Pro.local>
	<CAHdjipKFKp3PmFHZ1Ykssg5aNPQRtbKq=ECawPvUmKFXoR_UMg@mail.gmail.com>
	<etPan.5295ce82.216231b.103@Garren-Smiths-MacBook-Pro.local>
	<etPan.5295d8ce.327b23c6.13d53@akai.jsonified.com>
	<CAHdjipKRba+JtZKw8RgTCJ0hbqBBrAERjMJW+N1aA4ULscU94Q@mail.gmail.com>
	<CABvT1DEkQ4RnxDun4uz0eGPvsVnLqeGb60o198kadM=nJX79dQ@mail.gmail.com>
	<CAHdjipJ38=hLBhG5X1CF-CNnNj88KDUTitkXJUvA+tzpVdZNQA@mail.gmail.com>
	<310B466DB648473A9C6135BF9F4B72A3@cloudant.com>
	<CAHdjipJ+aTEq9jeYjzzaVMObYfmF-Z2JksLcYFz8ZQOo=twFKg@mail.gmail.com>
	<CABvT1DGqYiUS64expuorEegc8TSTSqKn+VEcbs3=qzOtmS_-sw@mail.gmail.com>
Date: Wed, 27 Nov 2013 17:26:20 +0400
Message-ID: 
 <CAHdjipKt+mevx2hDuhSQGc6u-d5uyMW+7HGTgd1ne7r3hGCm9A@mail.gmail.com>
Subject: Re: couchdb pull request: Handle req.status == 201
From: Alexander Shorin <kxepal@gmail.com>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Robert,

I understand all of this, but it seems we're talking about bit
different things. You're right that this change will require major
version bump - I'm totally agree on that.

But I'd talking about that if there already will be the window of
major version bump due to bigcouch/rcouch merges it's wise to remove
jquery.couch within this windows instead of creating new major version
just for this change. Better to accumulate breaking changes and
release them in batch rather than one by one bumping major version for
every next release - that's the idea. Otherwise we wouldn't be better
than Chromium or Firefox when you couldn't say for sure how version X
is better than X-1 (:


--
,,,^..^,,,


On Wed, Nov 27, 2013 at 4:51 PM, Robert Newson <rnewson@apache.org> wrote:
> "where nothing changed,"
>
> Removing jquery.couch.js will *break* some users. Neither of us know
> how many users that is, or which users it is. The major version bump
> is necessary to communicate this ("MAJOR version when you make
> incompatible API changes"). We can deprecate it without needing to
> bump the major, if that's our decision.
>
> A big part of semver is to stop being so precious about version
> numbers. It codifies rules for version numbers for the sole intention
> of conveying compatibility. You know that if your code works against
> X.0.0 then it ill also work against X.1.0 and X.0.1. For example, if
> the bigcouch merge didn't change API then we would not bump the major
> for it (but we would bump the minor).
>
> B.
>
> On 27 November 2013 12:39, Alexander Shorin <kxepal@gmail.com> wrote:
>> On Wed, Nov 27, 2013 at 4:06 PM, Simon Metson <simon@cloudant.com> wrote=
:
>>> If the library is getting taken out to be maintained in an external rep=
o why not just maintain it in the asf one? The reason for deprecating it wo=
uld be to be honest that it=E2=80=99s not maintained code, if someone is ma=
intaining it then great, keep it in!
>>>
>>> That it=E2=80=99s not used by fauxton is immaterial imho.
>>
>> There are some thoughts about in the related ticket:
>> https://issues.apache.org/jira/browse/COUCHDB-1934
>>
>> Deprecated means that it becomes excluded from the CouchDB project.
>> Probably, the word "deprecated" isn't correct one for this case.
>>
>> Personally, I have nothing against jquery.couch and if it will left in
>> main repo it will be fine. But if no part of the project will use it
>> (after fauxton  stable release), it's reasonable to ask what it does
>> in the source tree and wouldn't it be better to move it outside of it?
>> That's all the talks (:
>>
>> --
>> ,,,^..^,,,