You can find the binaries in the usual places:
https://dist.apache.org/repos/dist/dev/couchdb/binary/win/3.0.1/rc.2/
https://dist.apache.org/repos/dist/dev/couchdb/binary/win/3.1.0/rc.2/
https://repo-nightly.couchdb.org/ (check in the 3.x and 3.0.x folders)
-Joan "enough CouchDB for today" Touz
Author: wohali
Date: Thu Apr 30 21:11:25 2020
New Revision: 39210
Log:
Adding Windows binaries for CouchDB 3.1.0-RC2 and 3.0.1-RC2 to dev tree
Added:
dev/couchdb/binary/win/3.0.1/
dev/couchdb/binary/win/3.0.1/rc.2/
dev/couchdb/binary/win/3.0.1/rc.2/apache-couchdb-3.0.1.msi (with pro
Testing my own release.
Platform: Windows 10 (1909) and Windows 7 (latest) x86_64
sha256 - matches
sha512 - matches
make check - still failing on the same 2 Elixir tests, but hand-patched.
I didn't cherry-pick the full fix from #2684 (f796cd1)
I don't feel this requires
Testing my own release.
Platform: Windows 10 (1909) and Windows 7 (latest) x86_64
sha256 - matches
sha512 - matches
make check - still failing on the same 2 Elixir tests, but hand-patched.
I didn't cherry-pick the full fix from #2684 (f796cd1)
I don't feel this requires
Dear community,
I would like to propose that we release Apache CouchDB 3.1.0.
Changes since the last round:
https://github.com/apache/couchdb/compare/3.1.0-RC1...3.1.0-RC2
Candidate release notes:
https://docs.couchdb.org/en/latest/whatsnew/3.1.html
We encourage the whole community to do
Dear community,
I would like to propose that we release Apache CouchDB 3.0.1.
Changes since the last round:
https://github.com/apache/couchdb/compare/3.0.1-RC1...3.0.1-RC2
Candidate release notes:
https://docs.couchdb.org/en/latest/whatsnew/3.0.html#version-3-0-1
We encourage the whole
Author: wohali
Date: Thu Apr 30 18:24:37 2020
New Revision: 39205
Log:
Adding CouchDB 3.0.1-RC2 and 3.1.0-RC2 to dev tree
Added:
dev/couchdb/source/3.0.1/rc.2/
dev/couchdb/source/3.0.1/rc.2/apache-couchdb-3.0.1-RC2.tar.gz (with props)
dev/couchdb/source/3.0.1/rc.2/apache-couchdb-3.0
Hi Ilya,
Maybe we should set a hard limit on the maximum doc ids size, 2-4KB?
We have a config setting to do it already. And we also have hard
limit of 10KB for FDB keys. Due to a limitation in Erlang http header
parser, used through mochiweb, 8KB is (was?) the limit based on the
default socket r
Vote is cancelled - I forgot to push the commit with the bumps to the
actual version numbers, and there's a missed backport of a Makefile.win fix.
PRs will be up shortly, and then RC2 will follow.
-Joan
On 2020-04-30 0:00, Joan Touzet wrote:
Dear community,
I would like to propose that we re
Vote is cancelled - I forgot to push the commit with the bumps to the
actual version numbers, and there's a missed backport of a Makefile.win fix.
PRs will be up shortly, and then RC2 will follow.
-Joan
On 2020-04-30 0:02, Joan Touzet wrote:
(YES, this is another -RC1, a simultaneous release
I think this is a good reason to fall back to just including the value of the
bookmark in “first”, “next” and “last”, and then leaving it up to the client to
decide whether to supply the bookmark in the URL or in the request body.
Adam
> On Apr 30, 2020, at 10:47 AM, Joan Touzet wrote:
>
> Ca
Can we keep a distributed hash of doc keys server side with a smaller
handle we hand to clients?
If the cache can't be found or a restart happens, oh well.
-Joan
On 2020-04-30 10:23, Ilya Khlopotov wrote:
There is a problem with representing `next`/`previous`/`first` as path. With
5kB sized
There is a problem with representing `next`/`previous`/`first` as path. With
5kB sized doc keys and we could exceed max URL length (8192 bytes). This means
we would have to support POST. The question is how to handle the case when the
URL is greater than 8192. The problem is CouchDB don't knows
13 matches
Mail list logo
