Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Hi Johs, Pull requests for 1.x continue to be welcome. But it's been almost two years since 2.0.0 was released - and I've seen none beyond trivial bug fixes. Were this proposal not to proceed, the only thing that would continue right now for 1.x is urgent security patches. I have already consulted with the active developers working on the master / 2.x branches - none have the time or inclination to continue working on 1.x backports, so there is no group of developers currently identified to fill that hypothetical 3-man team. Are you volunteering? I'm not saying "no" to backporting, but I am saying that no one has done so to date, and making a prediction that chances are very slim that it'll change in the foreseeable future. As for things in 2.x that are "must fix" before people can upgrade, I too would like to see pull requests for those. Once again, your help is most welcome in this - both in identifying a definitive list of those must-fix issues, as well as code towards fixing them. If you'd like to help with this important work, please start a new thread. I realize we see things differently from where we each sit, but 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. I feel as a result the time is right to make this proposal. Thanks for your feedback. -Joan - Original Message - From: "Johs Ensby" To: "dev@couchdb.apache.org Developers" , "Joan Touzet" Sent: Wednesday, July 4, 2018 6:06:06 PM Subject: Re: [PROPOSAL] Officially deprecate CouchDB 1.x. Joan, thanks for your relentless effort to focus resources on moving 2.x forward. That said, I honestly dont see how this proposal would support your intentions 1) Migration to to 2.x would have happened already if a production ready version was available 2) Leaving 1.x out in the cold will not speed up migration to 2.x for the above reason 3) To drop support before migration is a success is a very risky move To me this is a reputation killer. When forward-looking decisions are made for or against the use of CouchDB, a minimum of two things must be in place. Confidence in the team pushing the next version forward and a commitment to keep supporting the users that want, but cannot upgrade as they wait for critical issues to be solved. My suggestion would be to move with some of the hopeful suggestions to see if some new resources would come out of the woodwork 1) A 3-person team should be actively encouraged into existence as a first step of a longer process 2) Your "no" to back-porting is reasonable if it draws resources from the main project, otherwise why curb the enthusiasm? 3) The decision to freeze (not abandon) should come as a consquense of 2.x fully satisfying the users with 1.x systems in production br Johs > On 4 Jul 2018, at 22:51, Joan Touzet 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
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Joan, thanks for your relentless effort to focus resources on moving 2.x forward. That said, I honestly dont see how this proposal would support your intentions 1) Migration to to 2.x would have happened already if a production ready version was available 2) Leaving 1.x out in the cold will not speed up migration to 2.x for the above reason 3) To drop support before migration is a success is a very risky move To me this is a reputation killer. When forward-looking decisions are made for or against the use of CouchDB, a minimum of two things must be in place. Confidence in the team pushing the next version forward and a commitment to keep supporting the users that want, but cannot upgrade as they wait for critical issues to be solved. My suggestion would be to move with some of the hopeful suggestions to see if some new resources would come out of the woodwork 1) A 3-person team should be actively encouraged into existence as a first step of a longer process 2) Your "no" to back-porting is reasonable if it draws resources from the main project, otherwise why curb the enthusiasm? 3) The decision to freeze (not abandon) should come as a consquense of 2.x fully satisfying the users with 1.x systems in production br Johs > On 4 Jul 2018, at 22:51, Joan Touzet 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
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
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 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 >
[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
