couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giovanni Lenzi <g.le...@smileupps.com>
Subject Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Date Fri, 06 Jul 2018 16:17:28 GMT
On Fri, Jul 6, 2018, 15:48 Jan Lehnardt <jan@apache.org> wrote:

>
>
> > On 6. Jul 2018, at 15:27, Jan Lehnardt <jan@apache.org> wrote:
> >
> >
> >
> >> On 6. Jul 2018, at 15:00, Giovanni Lenzi <g.lenzi@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
>

Just to have our pull requests rejected? No thanks, We learned something
from the past.

Just take what I said as a big and free survey to your users and their
needs.. After that, you are free to develop what it makes you feel better



> >
> >
> >>
> >>
> >> --Giovanni
> >>
> >> 2018-07-05 19:43 GMT+02:00 Alexander Shorin <kxepal@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 <wohali@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/
>
>

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