All: Though this wasn't an official VOTE, the results are:
* 8 +1 votes, all from committers on the project. * 2 -1 votes from non-committer dev@ members who would like to keep using 1.x until they are able to safely migrate to 2.x. The intent of the proposal was to get broad community consensus on the approach. What I'm seeing is a disconnect between a small portion of the community - who enjoy and appreciate CouchDB, but who are unable to upgrade to 2.x at this time - and the developers who actually build and release CouchDB, who are no longer prepared to support them with 1.x releases. (As a reminder: other than a few trivial commits to prepare security releases, the 1.x branches have had no activity since December 2015.) While this is unfortunate, we have to recognize reality: without the developers to support 1.x, it is dishonest and inappropriate for this project to pretend it is still supporting CouchDB 1.x as a first class release branch that still receives regular updates. At this time, I think there is no choice but to discontinue 1.x security releases. (As previously stated, there already were no other 1.x releases planned or in the works.) In the event of a serious security problem being disclosed to secur...@couchdb.apache.org, this could be revisited on a case-by-case basis. So what happens now? * Our code repository at https://gitbox.apache.org/repos/asf/couchdb.git and at https://github.com/apache/couchdb will continue to hold a copy of the 1.x release code. * https://couchdb.apache.org/ does not change for now. At some point in the future, probably with the 3.0.0 release, all references to 1.x downloads will be removed. At that time, downloads of the 1.x release assets will be available only through the archive at https://archive.apache.org/dist/couchdb/. * All issues related to 1.x on GitHub and JIRA will be closed with a comment stating that official 1.x support has ended. If those issues still apply to 2.x, the issues will be updated and brought into consideration for resolution in a future CouchDB release. * Issues related to 1.x->2.x migration, as summarised on the user@ mailing list recently, should be prioritised for inclusion in a new release of CouchDB *as soon as possible*. * PRs against the 1.7.x branch are welcome for security issues, which might trigger a 1.x release, but there is no guarantee that such will happen. * The next release of CouchDB will be 2.2.0, which already contains several exciting features (such as the pluggable storage backend). * Once again I encourage community fork projects of 1.x. The only limitations are the Apache License v2.0, and that you can't call your fork "CouchDB" or "Apache CouchDB". Thank you for your time, Joan "It's never easy to say goodbye" Touzet ----- Original Message ----- > From: "Joan Touzet" <woh...@apache.org> > To: dev@couchdb.apache.org > Sent: Wednesday, July 4, 2018 4:51:15 PM > Subject: [PROPOSAL] Officially deprecate CouchDB 1.x. > > 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 >
