nickva commented on issue #4467: URL: https://github.com/apache/couchdb/issues/4467#issuecomment-1464005748
Great idea, @janl. I a good page to keep an eye on is [upcoming_incompatibilities](https://www.erlang.org/doc/general_info/upcoming_incompatibilities.html) For clouseau (search) which implements its own dist protocol there are some thing to fix up: - [ ] DFLAG_V4_NC - [ ] [New link protocol](https://www.erlang.org/doc/apps/erts/erl_dist_protocol.html#new_link_protocol) is mandatory A tricky one may be that term_to_binary is changing: - [ ] [erlang:term_to_binary/1,2](https://www.erlang.org/doc/man/erlang.html#term_to_binary-1) and [erlang:term_to_iovec/1,2](https://www.erlang.org/doc/man/erlang.html#term_to_iovec-1) will now encode atoms as UTF8 by default. We use term_to_binary for on-disk storage. I think we can try toggling `{minor_version, 2}` in more places to ensure we use a forward compatible format. As far back as R16 can already read that format. A potential pitfall here is a case where in the compactor we may not necessarily re-encode all doc bodies or other bits when we copy. That means we could potentially carry forward future-incompatible compression format, or term_to_binary ({minor_version, 0} ?) or such without noticing or compaction having a way to upgrade it. - [ ] [erlang:term_to_binary/1,2](https://www.erlang.org/doc/man/erlang.html#term_to_binary-1) has a new `deterministic` option since OTP 24. ```can be used to ensure that within the same major release of Erlang/OTP, the same encoded representation is returned for the same term. There is still no guarantee that the encoded representation remains the same between major releases of Erlang/OTP.``` wonder if there is any need or use for that. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@couchdb.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
