couchdb-couchapp mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ermouth <>
Subject On 1.x deprecation
Date Thu, 05 Jul 2018 23:44:55 GMT
TLDR; Please vote -1 at @dev thread ‘[PROPOSAL] Officially deprecate
CouchDB 1.x.’ All arguments of the proposal are of no basis.


Hope, we all read deprecation statement from Joan. She provided one reason
directly, also several were coined in indirect way.

1. “No one is maintaining the 1.x.x branches of CouchDB anymore”

Probably that’s because they just do not need daily maintenance.

2. “Issues stack up on the tracker with no response.”

Ok, lets count. Right now couchdb github repo has 133 issues open, 11 of
them have 1.x tag.

21 of those 133 are marked with red bug tag, but none of them with 1.x. So
seems 1.x have no serious bugs, but 2.x have a pile.

How about “no response”? All 1.x issues have at least one. 33% of non-1.x
issues have zero answers. So I’d say if there exist a stack up, it’s not
related to 1.x, it’s more about 2.x.

3. “Having to patch 1.x as well as 2.x slows down the security team's
ability to push releases quickly out the door”

First, this game is two-sided. Probably, necessaty to fix not so adopted
version slowed down the team from releasing very minor upgrade for very
stable version widely used in production.

Probably, back-porting of not widely adopted 2.x features into 1.7 also
slowed process down.

Or, probably, there were no slowdown at all? As I know, that ‘slow down’
was never complained.

4. “By focusing on what we do best - supporting 2.x”

As I showed earlier it’s looks incomparably easier to support 1.x than 2.x.
As I can see from numbers, supporting 2.x issues have already taken all
focus. It happened about 1.5 years ago I’d say.

Ok, have anyone ever complained? Today I consulted a guy from BY by phone,
yesterday from IN – also privately. Classic reasonable CouchDB guys seem to
be pretty well aware they won’t have a lot of help from official support
anyway. They do not need bug fixes, they want to discuss use strategies,
solution details, they want hints and opinions how to improve things that
already works fine.

So 1.x doesn’t blur developers’ focus, unless developers start demnding
granny’s blood. Granny is still pretty healthy.

5. “I’m definitely seeing more people on 2.x these days than 1.x,
*significantly* more - both from our informal support channels as well as
through GitHub Issues and requests for paid support”

This argument is very strange. It looks like someone already have a lot of
2.x tickets and want even more. Sorry, but I don’t see how it reflects real
users distribution, I only see that 2.x is more buggy and though sells paid
support better.


So, as I see all above arguments for deprecation have no relation to real
accountable state of things, unless I suppose the goal is paid support.
Honestly, I can’t believe in it.

Then why deprecate?

The deprecation notice by itself breaks reputation of 1.6/1.7, which is for
now waaay more reliable than 2.x. At least 1.6 doesn’t bite unexpectedly.

I hope keeping things as is for about a year is well enough to fix most
visible 2.x issues, and then – long live 1.x.

Unfortunately I’m not subscribed to @dev and can’t reply into past proposal
thread even if get subscribed now.

So if you feel my arguments are reasonable, I ask you to cast ‘-1’ under
that proposal. Thank you.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message