As you've said there are no big contributions to 1.x branches for few years. I am not sure how many users use 1.x releases. However, I do believe that spending resources on releases for very old versions is counterproductive. It would be better for the project if these resources would be spent elsewhere. I am in favor of deprecating 1.x
Best regards, @iilyak On 2018/07/04 20:51:15, 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 >