couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Date Sun, 08 Jul 2018 15:58:47 GMT
There might be a misunderstanding of what is required to keep 1.x from being deprecated.

It is not a detailed plan, lengthy discussion, or request for features or extended support.

It is people spending the time in the code and issues to prepare branches that they then produce
release candidates of. The changes and issues triaged can be bugfixes and security fixes.

Until the people who end up doing this, do not materialise, there is little sense in further
discussions, as merely making requests for work and not putting in the work are a decent waste
of everybody’s time.

Note how number of users/downloads/etc doesn’t factor into the above.

But while we are at it, from 75 responses to the CouchDB survey so far, we have about 30%
1.x users. That’s down from ~70% in the 2017 survey (of 130 people). Note that multiple
answers were possible, so the 1.x operators might also run 2.x.

Those numbers and the trend along with everything else, I’m confident in deprecating 1.x.
1.x is a fine piece of software and existing installations of it will continue to run just
fine, but this project is moving on.


> On 8. Jul 2018, at 14:59, Johs Ensby <> wrote:
> Thanks Joan,
> Your take on the data is
>> To me the data is more proof that asking to keep 1.x on a lifeline is
>> serving a vanishingly small amount of users.
> I see no proof in the data and I disagree with respect how to best go about "serving
a vanishingly small amount of users."
> My take on the data is guesswork, but I would love to see someone tare it down with data:
> 1) Millions have played with CouchDB (we are now left with a vanishingly small amount
of these)
> 2) Tens of thousands of servers are running with CouchDB today
>    (20 000+ downloads of 2.x for Debian/Ubuntu/CebtOs/RHEL over a year indicate intention
to upgrade, however, not actual upgrade)
> 3) Average 100+/day downloads of 2.1.1 is another indicator of upgrade activity being
> 4) Thousands of sysops/sysdevs have CouchDB 1.x as part of their stack, they have not
been heard in this discussion yet
> 5) Regarding developer activity and experimentation, the spikes connected to releases
are interesting:
> -- 2,237 downloads of 1.7.1 for Windows on the same day early January is a significant
spike that I don't know the background for.
> -- Spikes for 2.x on Mac indicate 600-900 active Mac-using developers, but we don't know
much about the sysops' plans to upgrade
> Regarding my offer to write a paper to make a case for keeping 1.x open you said
>>>> Thanks for the offer. Before writing up a full paper, what would
>>>> your first 3 acts be?
> I thought you wanted me to hold my horses and do this step by step
> It would be a bit akward to start discussing the point 2-3 until having feeback on my
> Should I proceed to point 1?
> I still think your proposal, as it was "tabled" had been better without the first what-it-means-point,
which is a far-reaching decision with unclear benefit.
> Also, I think the result of the recent user survey should be published to support the
decision making.
> Johs
>> On 7 Jul 2018, at 19:18, Joan Touzet <> wrote:
>> Johs Ensby wrote:
>>> Thanks for this, Joan
>>> You must have put a lot time and effort into this and it is _highly
>>> appreciated_.
>> You're welcome.
>>> The "official" seems
>>> like a
>>> nice place to follow the trend. 
>> For a limited amount of data, compared to how popular the binary
>> distributions from are, yes.
>> If Infra is able to give us access to the archived closer.lua data,
>> we should be able to get a better picture of relative popularity,
>> at least for people who click through to
>> download the tarball.
>>> What is in second column, download
>>> time?
>> The script that generates the file is at:
>> That field is generated on line 464, which is grabbing the final octet
>> of the IP address for uniqueness. This can help de-duplicate data, or
>> look for "ballot-stuffing" by someone trying to make one download or the
>> other look more popular. ;)
>>> Although it is hard to compile totals out of this, the fact that the
>>> numbers are
>>> small is a fact. 
>> Again, compared to the binary downloads. Including the Docker downloads
>> (which do not separate by version #, which is why I haven't included them
>> in my email) there are 30+ million downloads of CouchDB in the wild.
>> To me the data is more proof that asking to keep 1.x on a lifeline is
>> serving a vanishingly small amount of users.
>>> Lost of upside and few people to deal with as the
>>> base,
>>> which means that anyone who value CouchDB today can make a huge
>>> impact, relatively speeking.
>> In terms of people making a large impact, it's more about the total
>> number of contributors and committers to the project. As a PMC member,
>> I want to see more contributors and committers who are interested in
>> making CouchDB better, not in publicity hounds who just want to pad
>> their resume by working on a high-profile OSS project. (Not pointing
>> fingers at you, just thinking out loud.)
>>> Thanks also for this response:
>>>> Thanks for the offer. Before writing up a full paper, what would
>>>> your
>>>> first 3 acts be?
>>> 1) State my intentions, for feedback
>>> 2) Table my case for a 1.x branch with limit scope, again for feeback
>>> 3) Table an outline
>> In terms of 1.x scope, my first choice is to end support for it.
>> Every single committer has voted +1 on this proposal so far; only you
>> and one other dev have cast non-binding votes against it.
>> If there is sufficient interest to continue with 1.x, the primary
>> need is for someone to maintain it for security patches only. This
>> would need to be established committer(s) on the project who would
>> be available rapidly to patch and spin new releases if and when any
>> security issues are raised by external reporters confidentially.
>> If there's even more interest beyond that, then the only scope
>> I can see is for bug fixes based on GitHub issue tracker posts, or
>> at the very most, back ports of any 2.x features or changes that
>> will make the migration to 2.x easier. This might include many
>> deprecation warnings we talked about at one point.
>> I don't want to see branched development on 1.x that adds new
>> 1.x-only features, or back ports of major new 2.x functionality
>> like Mango or clustering.
>> I don't speak for the rest of the PMC on this.
>> -Joan

View raw message