Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
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" > 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
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Roger that, over and out. Johs > On 8 Jul 2018, at 17:58, Jan Lehnardt wrote: > > There might be a misunderstanding of what is required to keep 1.x from being > deprecated. > > It is not a detailed plan, lengthy discussion, or request for features or > extended support. > > It is people spending the time in the code and issues to prepare branches > that they then produce release candidates of. The changes and issues triaged > can be bugfixes and security fixes. > > Until the people who end up doing this, do not materialise, there is little > sense in further discussions, as merely making requests for work and not > putting in the work are a decent waste of everybody’s time. > > Note how number of users/downloads/etc doesn’t factor into the above. > > But while we are at it, from 75 responses to the CouchDB survey so far, we > have about 30% 1.x users. That’s down from ~70% in the 2017 survey (of 130 > people). Note that multiple answers were possible, so the 1.x operators might > also run 2.x. > > Those numbers and the trend along with everything else, I’m confident in > deprecating 1.x. 1.x is a fine piece of software and existing installations > of it will continue to run just fine, but this project is moving on. > > Best > Jan > — > >> On 8. Jul 2018, at 14:59, Johs Ensby wrote: >> >> Thanks Joan, >> >> Your take on the data is >>> To me the data is more proof that asking to keep 1.x on a lifeline is >>> serving a vanishingly small amount of users. >> >> >> I see no proof in the data and I disagree with respect how to best go about >> "serving a vanishingly small amount of users." >> >> My take on the data is guesswork, but I would love to see someone tare it >> down with data: >> >> 1) Millions have played with CouchDB (we are now left with a vanishingly >> small amount of these) >> 2) Tens of thousands of servers are running with CouchDB today >> (20 000+ downloads of 2.x for Debian/Ubuntu/CebtOs/RHEL over a year >> indicate intention to upgrade, however, not actual upgrade) >> 3) Average 100+/day downloads of 2.1.1 is another indicator of upgrade >> activity being strong. >> 4) Thousands of sysops/sysdevs have CouchDB 1.x as part of their stack, they >> have not been heard in this discussion yet >> 5) Regarding developer activity and experimentation, the spikes connected to >> releases are interesting: >> -- 2,237 downloads of 1.7.1 for Windows on the same day early January is a >> significant spike that I don't know the background for. >> -- Spikes for 2.x on Mac indicate 600-900 active Mac-using developers, but >> we don't know much about the sysops' plans to upgrade >> >> Regarding my offer to write a paper to make a case for keeping 1.x open you >> said > Thanks for the offer. Before writing up a full paper, what would > your first 3 acts be? >> I thought you wanted me to hold my horses and do this step by step >> It would be a bit akward to start discussing the point 2-3 until having >> feeback on my intentions. >> Should I proceed to point 1? >> >> I still think your proposal, as it was "tabled" had been better without the >> first what-it-means-point, which is a far-reaching decision with unclear >> benefit. >> Also, I think the result of the recent user survey should be published to >> support the decision making. >> >> Johs >> >> >>> On 7 Jul 2018, at 19:18, Joan Touzet wrote: >>> >>> Johs Ensby wrote: Thanks for this, Joan You must have put a lot time and effort into this and it is _highly appreciated_. >>> >>> You're welcome. >>> The "official" https://www-us.apache.org/dyn/stats/couchdb.log seems like a nice place to follow the trend. >>> >>> For a limited amount of data, compared to how popular the binary >>> distributions from bintray.com are, yes. >>> >>> If Infra is able to give us access to the archived closer.lua data, >>> we should be able to get a better picture of relative popularity, >>> at least for people who click through https://couchdb.apache.org/ to >>> download the tarball. >>> What is in second column, download time? >>> >>> The script that generates the file is at: >>> >>> https://svn.apache.org/viewvc/infrastructure/site/trunk/content/dyn/closer.lua?view=markup >>> >>> That field is generated on line 464, which is grabbing the final octet >>> of the IP address for uniqueness. This can help de-duplicate data, or >>> look for "ballot-stuffing" by someone trying to make one download or the >>> other look more popular. ;) >>> Although it is hard to compile totals out of this, the fact that the numbers are small is a fact. >>> >>> Again, compared to the binary downloads. Including the Docker downloads >>> (which do not separate by version #, which is why I haven't included them >>> in my email) there are 30+ million downloads of CouchDB in the wild. >>> >>> To me the data is more proof that asking to keep 1.x on a lifeline is >>> serving a
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
There might be a misunderstanding of what is required to keep 1.x from being deprecated. It is not a detailed plan, lengthy discussion, or request for features or extended support. It is people spending the time in the code and issues to prepare branches that they then produce release candidates of. The changes and issues triaged can be bugfixes and security fixes. Until the people who end up doing this, do not materialise, there is little sense in further discussions, as merely making requests for work and not putting in the work are a decent waste of everybody’s time. Note how number of users/downloads/etc doesn’t factor into the above. But while we are at it, from 75 responses to the CouchDB survey so far, we have about 30% 1.x users. That’s down from ~70% in the 2017 survey (of 130 people). Note that multiple answers were possible, so the 1.x operators might also run 2.x. Those numbers and the trend along with everything else, I’m confident in deprecating 1.x. 1.x is a fine piece of software and existing installations of it will continue to run just fine, but this project is moving on. Best Jan — > On 8. Jul 2018, at 14:59, Johs Ensby wrote: > > Thanks Joan, > > Your take on the data is >> To me the data is more proof that asking to keep 1.x on a lifeline is >> serving a vanishingly small amount of users. > > > I see no proof in the data and I disagree with respect how to best go about > "serving a vanishingly small amount of users." > > My take on the data is guesswork, but I would love to see someone tare it > down with data: > > 1) Millions have played with CouchDB (we are now left with a vanishingly > small amount of these) > 2) Tens of thousands of servers are running with CouchDB today >(20 000+ downloads of 2.x for Debian/Ubuntu/CebtOs/RHEL over a year > indicate intention to upgrade, however, not actual upgrade) > 3) Average 100+/day downloads of 2.1.1 is another indicator of upgrade > activity being strong. > 4) Thousands of sysops/sysdevs have CouchDB 1.x as part of their stack, they > have not been heard in this discussion yet > 5) Regarding developer activity and experimentation, the spikes connected to > releases are interesting: > -- 2,237 downloads of 1.7.1 for Windows on the same day early January is a > significant spike that I don't know the background for. > -- Spikes for 2.x on Mac indicate 600-900 active Mac-using developers, but we > don't know much about the sysops' plans to upgrade > > Regarding my offer to write a paper to make a case for keeping 1.x open you > said Thanks for the offer. Before writing up a full paper, what would your first 3 acts be? > I thought you wanted me to hold my horses and do this step by step > It would be a bit akward to start discussing the point 2-3 until having > feeback on my intentions. > Should I proceed to point 1? > > I still think your proposal, as it was "tabled" had been better without the > first what-it-means-point, which is a far-reaching decision with unclear > benefit. > Also, I think the result of the recent user survey should be published to > support the decision making. > > Johs > > >> On 7 Jul 2018, at 19:18, Joan Touzet wrote: >> >> Johs Ensby wrote: >>> Thanks for this, Joan >>> >>> You must have put a lot time and effort into this and it is _highly >>> appreciated_. >> >> You're welcome. >> >>> The "official" https://www-us.apache.org/dyn/stats/couchdb.log seems >>> like a >>> nice place to follow the trend. >> >> For a limited amount of data, compared to how popular the binary >> distributions from bintray.com are, yes. >> >> If Infra is able to give us access to the archived closer.lua data, >> we should be able to get a better picture of relative popularity, >> at least for people who click through https://couchdb.apache.org/ to >> download the tarball. >> >>> What is in second column, download >>> time? >> >> The script that generates the file is at: >> >> https://svn.apache.org/viewvc/infrastructure/site/trunk/content/dyn/closer.lua?view=markup >> >> That field is generated on line 464, which is grabbing the final octet >> of the IP address for uniqueness. This can help de-duplicate data, or >> look for "ballot-stuffing" by someone trying to make one download or the >> other look more popular. ;) >> >>> Although it is hard to compile totals out of this, the fact that the >>> numbers are >>> small is a fact. >> >> Again, compared to the binary downloads. Including the Docker downloads >> (which do not separate by version #, which is why I haven't included them >> in my email) there are 30+ million downloads of CouchDB in the wild. >> >> To me the data is more proof that asking to keep 1.x on a lifeline is >> serving a vanishingly small amount of users. >> >>> Lost of upside and few people to deal with as the >>> base, >>> which means that anyone who value CouchDB today can make a huge >>> impact, relatively speeking. >> >> In terms of people
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Thanks Joan, Your take on the data is > To me the data is more proof that asking to keep 1.x on a lifeline is > serving a vanishingly small amount of users. I see no proof in the data and I disagree with respect how to best go about "serving a vanishingly small amount of users." My take on the data is guesswork, but I would love to see someone tare it down with data: 1) Millions have played with CouchDB (we are now left with a vanishingly small amount of these) 2) Tens of thousands of servers are running with CouchDB today (20 000+ downloads of 2.x for Debian/Ubuntu/CebtOs/RHEL over a year indicate intention to upgrade, however, not actual upgrade) 3) Average 100+/day downloads of 2.1.1 is another indicator of upgrade activity being strong. 4) Thousands of sysops/sysdevs have CouchDB 1.x as part of their stack, they have not been heard in this discussion yet 5) Regarding developer activity and experimentation, the spikes connected to releases are interesting: -- 2,237 downloads of 1.7.1 for Windows on the same day early January is a significant spike that I don't know the background for. -- Spikes for 2.x on Mac indicate 600-900 active Mac-using developers, but we don't know much about the sysops' plans to upgrade Regarding my offer to write a paper to make a case for keeping 1.x open you said >>> Thanks for the offer. Before writing up a full paper, what would >>> your first 3 acts be? I thought you wanted me to hold my horses and do this step by step It would be a bit akward to start discussing the point 2-3 until having feeback on my intentions. Should I proceed to point 1? I still think your proposal, as it was "tabled" had been better without the first what-it-means-point, which is a far-reaching decision with unclear benefit. Also, I think the result of the recent user survey should be published to support the decision making. Johs > On 7 Jul 2018, at 19:18, Joan Touzet wrote: > > Johs Ensby wrote: >> Thanks for this, Joan >> >> You must have put a lot time and effort into this and it is _highly >> appreciated_. > > You're welcome. > >> The "official" https://www-us.apache.org/dyn/stats/couchdb.log seems >> like a >> nice place to follow the trend. > > For a limited amount of data, compared to how popular the binary > distributions from bintray.com are, yes. > > If Infra is able to give us access to the archived closer.lua data, > we should be able to get a better picture of relative popularity, > at least for people who click through https://couchdb.apache.org/ to > download the tarball. > >> What is in second column, download >> time? > > The script that generates the file is at: > > https://svn.apache.org/viewvc/infrastructure/site/trunk/content/dyn/closer.lua?view=markup > > That field is generated on line 464, which is grabbing the final octet > of the IP address for uniqueness. This can help de-duplicate data, or > look for "ballot-stuffing" by someone trying to make one download or the > other look more popular. ;) > >> Although it is hard to compile totals out of this, the fact that the >> numbers are >> small is a fact. > > Again, compared to the binary downloads. Including the Docker downloads > (which do not separate by version #, which is why I haven't included them > in my email) there are 30+ million downloads of CouchDB in the wild. > > To me the data is more proof that asking to keep 1.x on a lifeline is > serving a vanishingly small amount of users. > >> Lost of upside and few people to deal with as the >> base, >> which means that anyone who value CouchDB today can make a huge >> impact, relatively speeking. > > In terms of people making a large impact, it's more about the total > number of contributors and committers to the project. As a PMC member, > I want to see more contributors and committers who are interested in > making CouchDB better, not in publicity hounds who just want to pad > their resume by working on a high-profile OSS project. (Not pointing > fingers at you, just thinking out loud.) > >> Thanks also for this response: >>> Thanks for the offer. Before writing up a full paper, what would >>> your >>> first 3 acts be? >> 1) State my intentions, for feedback >> 2) Table my case for a 1.x branch with limit scope, again for feeback >> 3) Table an outline > > In terms of 1.x scope, my first choice is to end support for it. > Every single committer has voted +1 on this proposal so far; only you > and one other dev have cast non-binding votes against it. > > If there is sufficient interest to continue with 1.x, the primary > need is for someone to maintain it for security patches only. This > would need to be established committer(s) on the project who would > be available rapidly to patch and spin new releases if and when any > security issues are raised by external reporters confidentially. > > If there's even more interest beyond that, then the only scope > I can see is for bug fixes based on GitHub issue tracker
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
> I don't want to see branched development on 1.x that adds new > 1.x-only features, or back ports of major new 2.x functionality > like Mango or clustering. I agree. Any future couchdb 1.x release will be security and bug fixes only. Not new features, not backports. B. > On 7 Jul 2018, at 18:18, Joan Touzet wrote: > > I don't want to see branched development on 1.x that adds new > 1.x-only features, or back ports of major new 2.x functionality > like Mango or clustering.
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Johs Ensby wrote: > Thanks for this, Joan > > You must have put a lot time and effort into this and it is _highly > appreciated_. You're welcome. > The "official" https://www-us.apache.org/dyn/stats/couchdb.log seems > like a > nice place to follow the trend. For a limited amount of data, compared to how popular the binary distributions from bintray.com are, yes. If Infra is able to give us access to the archived closer.lua data, we should be able to get a better picture of relative popularity, at least for people who click through https://couchdb.apache.org/ to download the tarball. > What is in second column, download > time? The script that generates the file is at: https://svn.apache.org/viewvc/infrastructure/site/trunk/content/dyn/closer.lua?view=markup That field is generated on line 464, which is grabbing the final octet of the IP address for uniqueness. This can help de-duplicate data, or look for "ballot-stuffing" by someone trying to make one download or the other look more popular. ;) > Although it is hard to compile totals out of this, the fact that the > numbers are > small is a fact. Again, compared to the binary downloads. Including the Docker downloads (which do not separate by version #, which is why I haven't included them in my email) there are 30+ million downloads of CouchDB in the wild. To me the data is more proof that asking to keep 1.x on a lifeline is serving a vanishingly small amount of users. > Lost of upside and few people to deal with as the > base, > which means that anyone who value CouchDB today can make a huge > impact, relatively speeking. In terms of people making a large impact, it's more about the total number of contributors and committers to the project. As a PMC member, I want to see more contributors and committers who are interested in making CouchDB better, not in publicity hounds who just want to pad their resume by working on a high-profile OSS project. (Not pointing fingers at you, just thinking out loud.) > Thanks also for this response: > > Thanks for the offer. Before writing up a full paper, what would > > your > > first 3 acts be? > 1) State my intentions, for feedback > 2) Table my case for a 1.x branch with limit scope, again for feeback > 3) Table an outline In terms of 1.x scope, my first choice is to end support for it. Every single committer has voted +1 on this proposal so far; only you and one other dev have cast non-binding votes against it. If there is sufficient interest to continue with 1.x, the primary need is for someone to maintain it for security patches only. This would need to be established committer(s) on the project who would be available rapidly to patch and spin new releases if and when any security issues are raised by external reporters confidentially. If there's even more interest beyond that, then the only scope I can see is for bug fixes based on GitHub issue tracker posts, or at the very most, back ports of any 2.x features or changes that will make the migration to 2.x easier. This might include many deprecation warnings we talked about at one point. I don't want to see branched development on 1.x that adds new 1.x-only features, or back ports of major new 2.x functionality like Mango or clustering. I don't speak for the rest of the PMC on this. -Joan
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Thanks for this, Joan You must have put a lot time and effort into this and it is _highly appreciated_. The "official" https://www-us.apache.org/dyn/stats/couchdb.log seems like a nice place to follow the trend. What is in second column, download time? Although it is hard to compile totals out of this, the fact that the numbers are small is a fact. Lost of upside and few people to deal with as the base, which means that anyone who value CouchDB today can make a huge impact, relatively speeking. Thanks also for this response: > Thanks for the offer. Before writing up a full paper, what would your > first 3 acts be? 1) State my intentions, for feedback 2) Table my case for a 1.x branch with limit scope, again for feeback 3) Table an outline Johs > On 6 Jul 2018, at 20:01, Joan Touzet wrote: > > Hi Johs, > > - Original Message - >> the flaw in measuring 2.x adoption by Github issues and requests for >> informal and paid support is that all these data points are pain >> points, >> not signs of error-free operation. >> The in-production part of CouchDB based systems is not easily >> measured, as one of the qualities of CouchDB has been zero downtime. >> The lack of data should just add caution before using the kill >> switch. > > Point taken, though there are still plenty of problems and bugs in 1.x, > and we're not seeing people come and ask for help with them in Slack, IRC, > on these lists or privately. > > Perhaps a better approach is to see the number of downloads of CouchDB > tarballs and packages, yes? We have access to this through our bintray.com > hosting and the apache.org mirror hierarchy. > > For the former, see graphs here: https://imgur.com/a/nI2bvnx > > Graph 1 shows downloads of the Windows package, which has the longest > download history available. Based on this we can see that the very large > majority of downloads of CouchDB is 2.x since the 2.0.0 release, and that > downloads had a palpable increase with this new version. 2017 still had ~10% > of > downloads as 1.x releases, but by the time 2.1.0 released last July, > this became background noise. > > With the release of 2.1.1 (see graph 2), 1.x accounts for less than 5% > of the downloads. > > Graphs 3 and 4 are the same data for the Mac downloads. Total downloads > are only 20% of the Windows downloads, but the overall trend of data is > the same. In fact, on OSX, in 2018 downloads of 2.1.0 alone exceed > downloads of 1.6.1, even after 2.1.1-1 was published. > > While I was at it, I checked download number for the new .deb/.rpm > packages (though we only provide 2.x packages). In the year the packages > have been available, we have ~20k downloads each on rpm and deb, with > debian users upgrading much more aggressively to 2.1.1 from 2.0.0 than > rpm users. See graphs 5 and 6. > > There is the possibility that Windows downloads are skewed, since I > expect this is more frequently in use on desktops rather than servers. > With 1.x packages removed from many distributions due to the age of > SpiderMonkey 1.8.5, our best bet is to look at tarball downloads from > the Apache mirror sites. Apache Infra logs requests through the web that > redirect people to their nearest mirror; this is the best data we have. > The exposed file: > > https://www-us.apache.org/dyn/stats/couchdb.log > > only covers the last 30 days; I've asked Infra if they can provide logs > farther back for a better statistical sample. > > Based on this file, using this program: > > https://gist.github.com/wohali/899a6d6c316d2f52c7a9cec0b3b41580 > > the count of downloads is: > > 0.8: 7 > 0.9: 18 > 0.11: 6 > 0.10: 6 > 1.0: 34 > 1.1: 41 > 1.2: 50 > 1.3: 19 > 1.4: 20 > 1.5: 23 > 1.6: 127 > 1.7: 201 > 2.0: 28 > 2.1: 717 > > As expected, there is a higher 1.x count here, but it still accounts for > less than half of the downloads, even when taking into account archived > versions < 1.7. > > If we only consider 1.6, 1.7, 2.0 and 2.1, 1.x downloads account for > 30% of tarball downloads. > > These download numbers are further dwarfed by the binary downloads above. > > > Turning to those older distributions, installations of CouchDB 1.x on > Debian have dropped significantly in the last couple of years: > > https://qa.debian.org/popcon.php?package=couchdb > > Ubuntu's data is skewed, due to the inclusion of CouchDB 1.1(1.2?) in > very old versions of Ubuntu One that is no longer used. Even accounting > for that, the data is similar, showing less than 500 active users of > the package: > > #Format > # > # is the package name; > # is the number of people who installed this package; > # is the number of people who use this package regularly; > # is the number of people who installed, but don't use this package > #regularly; > # is the number of people who upgraded this package recently; > # is the number of people whose entry didn't contain enough > #information (atime and ctime were 0). > #rank name
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Hi Johs, - Original Message - > the flaw in measuring 2.x adoption by Github issues and requests for > informal and paid support is that all these data points are pain > points, > not signs of error-free operation. > The in-production part of CouchDB based systems is not easily > measured, as one of the qualities of CouchDB has been zero downtime. > The lack of data should just add caution before using the kill > switch. Point taken, though there are still plenty of problems and bugs in 1.x, and we're not seeing people come and ask for help with them in Slack, IRC, on these lists or privately. Perhaps a better approach is to see the number of downloads of CouchDB tarballs and packages, yes? We have access to this through our bintray.com hosting and the apache.org mirror hierarchy. For the former, see graphs here: https://imgur.com/a/nI2bvnx Graph 1 shows downloads of the Windows package, which has the longest download history available. Based on this we can see that the very large majority of downloads of CouchDB is 2.x since the 2.0.0 release, and that downloads had a palpable increase with this new version. 2017 still had ~10% of downloads as 1.x releases, but by the time 2.1.0 released last July, this became background noise. With the release of 2.1.1 (see graph 2), 1.x accounts for less than 5% of the downloads. Graphs 3 and 4 are the same data for the Mac downloads. Total downloads are only 20% of the Windows downloads, but the overall trend of data is the same. In fact, on OSX, in 2018 downloads of 2.1.0 alone exceed downloads of 1.6.1, even after 2.1.1-1 was published. While I was at it, I checked download number for the new .deb/.rpm packages (though we only provide 2.x packages). In the year the packages have been available, we have ~20k downloads each on rpm and deb, with debian users upgrading much more aggressively to 2.1.1 from 2.0.0 than rpm users. See graphs 5 and 6. There is the possibility that Windows downloads are skewed, since I expect this is more frequently in use on desktops rather than servers. With 1.x packages removed from many distributions due to the age of SpiderMonkey 1.8.5, our best bet is to look at tarball downloads from the Apache mirror sites. Apache Infra logs requests through the web that redirect people to their nearest mirror; this is the best data we have. The exposed file: https://www-us.apache.org/dyn/stats/couchdb.log only covers the last 30 days; I've asked Infra if they can provide logs farther back for a better statistical sample. Based on this file, using this program: https://gist.github.com/wohali/899a6d6c316d2f52c7a9cec0b3b41580 the count of downloads is: 0.8: 7 0.9: 18 0.11: 6 0.10: 6 1.0: 34 1.1: 41 1.2: 50 1.3: 19 1.4: 20 1.5: 23 1.6: 127 1.7: 201 2.0: 28 2.1: 717 As expected, there is a higher 1.x count here, but it still accounts for less than half of the downloads, even when taking into account archived versions < 1.7. If we only consider 1.6, 1.7, 2.0 and 2.1, 1.x downloads account for 30% of tarball downloads. These download numbers are further dwarfed by the binary downloads above. Turning to those older distributions, installations of CouchDB 1.x on Debian have dropped significantly in the last couple of years: https://qa.debian.org/popcon.php?package=couchdb Ubuntu's data is skewed, due to the inclusion of CouchDB 1.1(1.2?) in very old versions of Ubuntu One that is no longer used. Even accounting for that, the data is similar, showing less than 500 active users of the package: #Format # # is the package name; # is the number of people who installed this package; # is the number of people who use this package regularly; # is the number of people who installed, but don't use this package #regularly; # is the number of people who upgraded this package recently; # is the number of people whose entry didn't contain enough #information (atime and ctime were 0). #rank nameinst vote old recent no-files (maintainer) 1209 couchdb-bin835764 453 83498418 309 (Unknown) Both distributions have removed CouchDB from their repos in the latest release. The very old Ubuntu Launchpad CouchDB PPA with 1.x packages has an API for querying the information, but I've not looked into it, because apparently it can take hours to gather the stats and I'm unconvinced the data will vary significantly from the easier-to-consume paths shown above. https://ftagada.wordpress.com/2011/01/05/ppa-stats-initial-impressions/ Conclusion: Based on this information there is poor evidence for the hypothesis that CouchDB 1.x is being downloaded with any sort of frequency. Of course, this does not mean that people don't already have it downloaded and are continuing to use it on already provisioned computing resources. > Yes, I am volunteering for a hypothetical 3-man team. I understand > that > such a team would not pull resources allready committed to 2.x, so > the >
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
I'd like to know more about this point: > Just to have our pull requests rejected? No thanks, We learned > something from the past. Developer goodwill is definitely in the interest of the PMC. I am troubled to hear that you had difficulty landing your PRs. Could you link to the PRs in question? What were the reasons your PRs were rejected? If constructive criticism was provided, were there reasons you were unable to make the requested changes to your PR? -Joan
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
On Fri, Jul 6, 2018, 15:48 Jan Lehnardt wrote: > > > > On 6. Jul 2018, at 15:27, Jan Lehnardt wrote: > > > > > > > >> On 6. Jul 2018, at 15:00, Giovanni Lenzi 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 : > >> > >>> 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 > 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 >
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
-1 A sunsetting discussion is very welcome, but this proposal is unclear, based on week arguments and a lack of data, and as decision support not the best of proposals. 1) To "table" a propoal for voting is problematic --- Joan specifically reference "non-US" meaning of the "table", which means "to begin consideration (or reconsideration) of a proposal". When listing what this proposal means i 4 points, her point 1 is the premature "kill swtich". It blocks any new or inactive developers from contributing. A proposal that is "tabled" should be revised before voted on, or you run the risk that it is a pure developer-centric decision. 2) Lack of data --- To use demand for support as a measure of usage can be misleading. 1.x users face less problems, therefore they are the easiest to support. As a minimum, the results from the recent survey should be presented to verify the support for abanoning 1.x at this stage. It would also be interesting to actively check the status of some hailmark installations like the npm Registry. 3) Lack of logic --- The argument for dropping 1.x is that: "No one is maintaining the 1.x.x branches.. By focusing [...] we can improve our release cadence" This makes no sense. There are no resources to reallocate to 2.x "to push releases quickly out the door." "avoid misleading our user base with false promises" To my knowledge, no promises have been made and complaints aired. Right now the couchdb github repo has 133 issues open 358 closed, 11 of them have 1.x tag. (2 closed). That is All the 1.x tickets could be closed with a "known issues note" explaining the decision to focus on 2.x issues. There are no red tag 1.x issues. Conclusion --- Tabeling a proposal that means: "The Apache CouchDB project will no longer make new 1.x releases." is not tabeling at all. It is a far-reaching, irreversible decision and to "sweethen" it with promises to endorce a new team or a thousand forks is really backwards. The discussion should be summed up in a final propsal whch is a less drastic sunsetting proposal to avoid spreading uncertainty amoung users and those that, while 2.x is still not bug-free, are making a forward-looking decision on what DB system to choose. Johs PS: all my opinions are IMHO, and I appreciate the efforts of the 2.x team very much > 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
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
> On 6. Jul 2018, at 15:27, Jan Lehnardt wrote: > > > >> On 6. Jul 2018, at 15:00, Giovanni Lenzi 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 : >> >>> 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 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]
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
> On 6. Jul 2018, at 15:00, Giovanni Lenzi 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? > > > --Giovanni > > 2018-07-05 19:43 GMT+02:00 Alexander Shorin : > >> 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 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/
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
-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 --Giovanni 2018-07-05 19:43 GMT+02:00 Alexander Shorin : > 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 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.
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 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.
+1 On Thu, Jul 5, 2018 at 5:18 AM Andy Wenk wrote: > > +1 > > -- > Andy Wenk > Hamburg - Germany > RockIt! > > GPG public key: > http://pgp.mit.edu/pks/lookup?op=get=0x45D3565377F93D29 > > > > > On 5. Jul 2018, at 11:21, Garren Smith wrote: > > > > +1 to this as well. We just don't have enough dev's to do this, and I would > > rather see us focusing on CouchDB 2.x > > > > On Thu, Jul 5, 2018 at 10:26 AM, Robert Samuel Newson > > wrote: > > > >> +1 > >> > >> I am also for the proposal to officially deprecate couchdb 1.x. > >> > >> I would not want to see back-porting or new feature work in 1.x even if a > >> theoretical 3 person team were to materialise. Of course any such team that > >> does appear could fork couchdb 1.x and work on it independently (the only > >> caveat being that it could not be called "couchdb"). > >> > >> I agree with Joan and Jan that we are simply recognising reality here. > >> There is no one developing on the 1.x branch and hasn't been for ages. It > >> is time for us to officially let it go. > >> > >> B. > >> > >>> On 5 Jul 2018, at 09:18, Jan Lehnardt wrote: > >>> > >>> > >>> > 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. > >>> > >>> +1 > >>> > >>> Best > >>> Jan > >>> — > > 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/ > >> > >> >
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
+1 -- Andy Wenk Hamburg - Germany RockIt! GPG public key: http://pgp.mit.edu/pks/lookup?op=get=0x45D3565377F93D29 > On 5. Jul 2018, at 11:21, Garren Smith wrote: > > +1 to this as well. We just don't have enough dev's to do this, and I would > rather see us focusing on CouchDB 2.x > > On Thu, Jul 5, 2018 at 10:26 AM, Robert Samuel Newson > wrote: > >> +1 >> >> I am also for the proposal to officially deprecate couchdb 1.x. >> >> I would not want to see back-porting or new feature work in 1.x even if a >> theoretical 3 person team were to materialise. Of course any such team that >> does appear could fork couchdb 1.x and work on it independently (the only >> caveat being that it could not be called "couchdb"). >> >> I agree with Joan and Jan that we are simply recognising reality here. >> There is no one developing on the 1.x branch and hasn't been for ages. It >> is time for us to officially let it go. >> >> B. >> >>> On 5 Jul 2018, at 09:18, Jan Lehnardt wrote: >>> >>> >>> 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. >>> >>> +1 >>> >>> Best >>> Jan >>> — 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/ >> >> signature.asc Description: Message signed with OpenPGP
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
+1 to this as well. We just don't have enough dev's to do this, and I would rather see us focusing on CouchDB 2.x On Thu, Jul 5, 2018 at 10:26 AM, Robert Samuel Newson wrote: > +1 > > I am also for the proposal to officially deprecate couchdb 1.x. > > I would not want to see back-porting or new feature work in 1.x even if a > theoretical 3 person team were to materialise. Of course any such team that > does appear could fork couchdb 1.x and work on it independently (the only > caveat being that it could not be called "couchdb"). > > I agree with Joan and Jan that we are simply recognising reality here. > There is no one developing on the 1.x branch and hasn't been for ages. It > is time for us to officially let it go. > > B. > > > On 5 Jul 2018, at 09:18, Jan Lehnardt wrote: > > > > > > > >> 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. > > > > +1 > > > > Best > > Jan > > — > >> > >> 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/ > >
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
+1 I am also for the proposal to officially deprecate couchdb 1.x. I would not want to see back-porting or new feature work in 1.x even if a theoretical 3 person team were to materialise. Of course any such team that does appear could fork couchdb 1.x and work on it independently (the only caveat being that it could not be called "couchdb"). I agree with Joan and Jan that we are simply recognising reality here. There is no one developing on the 1.x branch and hasn't been for ages. It is time for us to officially let it go. B. > On 5 Jul 2018, at 09:18, Jan Lehnardt wrote: > > > >> 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. > > +1 > > Best > Jan > — >> >> 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/
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Hi Johs, while I understand that corporate policies involved with saying a version is end-of-life (e.g. “we must migrate off it”), there is nobody stopping anyone from continuing to run 1.x in a setup where it is already running fine and security updates are not a concern. In fact we have a number of customers that we’d advise to continue to stay on 1.x, despite the potential deprecation. As such, I’m not seeing this proposal as “the kill switch”, as you call it. There is merely making policy what has been reality for the better part of two years in terms of focus for the team. Whatever “reputation damage” is there, we have already incurred it. Best Jan -- > On 5. Jul 2018, at 06:31, Joan Touzet wrote: > > 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. >&
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
> 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. +1 Best Jan — > > 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/
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Joan, the flaw in measuring 2.x adoption by Github issues and requests for informal and paid support is that all these data points are pain points, not signs of error-free operation. The in-production part of CouchDB based systems is not easily measured, as one of the qualities of CouchDB has been zero downtime. The lack of data should just add caution before using the kill switch. > 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? Yes, I am volunteering for a hypothetical 3-man team. I understand that such a team would not pull resources allready committed to 2.x, so the hope would be that presently non-actice developers could be persuaded to join an effort with limited, but a forward-looking scope. Noone should be expected to work for a branch that is doomed to die. If the PMC support for and effort to keep 1.x alive can be expressed clearly, I can develop a discussion paper for a hypotetical team as a start. > 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 will. br Johs > On 5 Jul 2018, at 06:31, Joan Touzet wrote: > > 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-l
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 offi
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
