> On 6. Jul 2018, at 15:27, Jan Lehnardt <j...@apache.org> wrote:
>
>
>
>> On 6. Jul 2018, at 15:00, Giovanni Lenzi <g.le...@smileupps.com> wrote:
>>
>> -1
>>
>> Since the release of CouchDB 2.x, we noticed a lot of new users coming to
>> Smileupps.com, where we provide 1.x support. Almost all our customers feel
>> that 1.x is very reliable and very simple to get their job done. On the
>> contrary 2.x is perceived as heavy, buggy, and not production ready. I
>> report here some thoughts directly reported from Smileupps customers:
>>
>> - CouchDB 2 has lot of bugs and open issues, not felt suitable for
>> production
>> - Too difficult to migrate
>> - Interested in having simple Couch on a single node
>> - 2 is too slow in single node configuration
>> - Interested in 1.x couchapps and _changes
>>
>> From our experience, developers are much more interested in features
>> decreasing their development time and easing their daily work( Futon UI /
>> design docs / rewrites ), instead of system features, like clustering,
>> which can eventually be obtained in other functionally similar ways at
>> higher or lower levels.
>>
>> I'm quite sure that deprecating 1.x will leave thousands of Couchdb users
>> in a state of limbo withouth real alternatives felt as reliable. That would
>> be definitely a reputation killer for the whole Couch project
>
> Would you be up for making some of our resources available for maintaining
> 1.x?
*your resources
Apologies.
>
>
>>
>>
>> --Giovanni
>>
>> 2018-07-05 19:43 GMT+02:00 Alexander Shorin <kxe...@gmail.com>:
>>
>>> 1.x, you was good and we'll never forget you, but it's time to move
>>> forward to better CouchDB future.
>>>
>>> +1, bury it!
>>> --
>>> ,,,^..^,,,
>>>
>>>
>>> On Wed, Jul 4, 2018 at 11:51 PM, Joan Touzet <woh...@apache.org> wrote:
>>>> DISCLAIMER: This is a non-technical proposal to make a project decision.
>>>> Per our Bylaws[1], this means that it should "normally be made with lazy
>>>> consensus, or by the entire community using discussion-led
>>>> consensus-building, and not through formal voting." However, since the
>>>> intent is to make a significant policy change, this concrete proposal
>>>> should be considered as a *lazy consensus* decision with a *7 day*
>>>> timeframe (expiring on or about 2017-07-11, 23:59 UTC. Please give this
>>>> thread your ample consideration.
>>>>
>>>>
>>>> I would like to table[2] a proposal to terminate official Apache support
>>>> for CouchDB 1.x. This means that:
>>>>
>>>> 1. The Apache CouchDB project will no longer make new 1.x releases.
>>>> 2. All remaining 1.x issues in JIRA and GH Issues will be closed.
>>>> 3. Everyone can continue to use 1.x as long as they want.
>>>> 4. People are welcome to continue discussing 1.x on the users@ list.
>>>>
>>>>
>>>> The reason is simple: no one is maintaining the 1.x.x branches of
>>>> CouchDB anymore. Issues stack up on the tracker[3] with no response.
>>>> Original grand plans of back-porting 2.x features such as Mango to 1.x
>>>> have not materialised. And when important security issues surface[4],
>>>> having to patch 1.x as well as 2.x slows down the security team's
>>>> ability to push releases quickly out the door.
>>>>
>>>> By focusing on what we do best - supporting 2.x and beyond with bug
>>>> fixes, new features, and ever-improving documentation and web UI - we
>>>> can improve our release cadence and avoid misleading our user base
>>>> with false promises.
>>>>
>>>>
>>>> THAT SAID: There are two important footnotes to the proposal.
>>>>
>>>> FIRST: If a group of interested maintainers start making active efforts
>>>> to improve 1.x branch upkeep, I can speak with the full authority of the
>>>> PMC to say that we'll endorse those efforts. But to un-mothball
>>>> 1.x officially should require more than 1-2 people doing occasional
>>>> bugfixing work. I'd personally want to see at least a 3-person team
>>>> making sustained contributions to 1.x before re-activating official
>>>> releases. Also, that work would need to be in-line with work currently
>>>> happening on master; I wouldn't want to see new 1.x features materialise
>>>> that don't have parallel commits to master. (Much preferred would be to
>>>> see people fixing the things in 2.x that prevent people migrating off
>>>> of 1.x instead.)
>>>>
>>>> SECOND: Let a thousand forks bloom. If you're looking to build a CouchDB
>>>> 1.x fork that has baked in geo/full text search, Mango, Fauxton, and
>>>> can run on VMS, OS/2 Warp 4, NeXTStep 3.x, and Palm, have at it. I'll
>>>> even write a blog post about your project. (Sounds interesting!)
>>>>
>>>>
>>>> Again, this proposal defaults to lazy consensus with a 7-day expiry
>>>> period. CouchDB committers have binding "votes" on this proposal.
>>>>
>>>> Thanks for your consideration,
>>>> Joan "to infinity, and beyond" Touzet
>>>>
>>>>
>>>> [1] http://couchdb.apache.org/bylaws.html#decisions
>>>> [2] In the non-U.S. sense of the word, i.e., meaning to begin
>>>> consideration of a proposal.
>>>> [3] https://s.apache.org/couchdb-1.x-issues
>>>> [4] https://s.apache.org/wdnW
>>>
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
