Benoit, Cloudant requires R14 support, it would mean our contribution to couchdb becomes useless to us and we could not contribute further.
B. On 22 Jan 2014, at 11:09, Alexander Shorin <[email protected]> wrote: > On Wed, Jan 22, 2014 at 2:49 PM, Benoit Chesneau <[email protected]> wrote: >> On Wed, Jan 22, 2014 at 11:35 AM, Alexander Shorin <[email protected]> wrote: >> >>> On Wed, Jan 22, 2014 at 2:19 PM, Benoit Chesneau <[email protected]> >>> wrote: >>>> On Tue, Jan 21, 2014 at 3:25 PM, Robert Samuel Newson < >>> [email protected]>wrote: >>>> >>>>> Definitely need to preserve R14 compatibility, that’s still the most >>>>> stable recent series (as long as you don’t use R14B02)… >>>>> >>>> >>>> >>>> I disagree. R14 hasn't been updated since more than 2 years, and isn't a >>>> supported version by the Erlang community, R17 will be out sometimes >>> during >>>> the spring. Latest versions added many fixes to SSL, improved the >>>> scheduling and memory usage, the NIF support and added a lot of >>>> improvements to the binary API. Also latest stables version of different >>>> distributions don't have any R14 any more (even RHEL). >>> >>> Well, the latest and stable CentOS 6.5 with EPEL 6.8 suggests me to >>> install R14 (R14B-04.3.el6), not R15 or R16 and I wouldn't be so sure >>> for others "stable" distros. Also shouldn't forget about production >>> environments where R14 is already used for some reasons and upgrade >>> isn't available. >>> >>> Production environnement that really take care of this aren't upgrading to >> the latest version as well.... Or they apply some confusing logic. They >> can't have one's cake and eat it too. >> >> Also see, mochiweb increased the latest requirements of the Erlang version, >> if we want to use latest changes like the websockets, then we will need to >> maintain our mochiweb version. How long should we do that? Also it will be >> worth with Erlang R17 which introduces breaking changes with r14 and >> initial r15 version. Maintain compatibility with all versions around is >> starting to be difficult and a time killer. >> >> I don't see why we should limit ourself because some are using an old thing >> in production. If we follow this path maybe we should also support erlang >> R11 which is still in production and a requirements in some big telecom >> companies around. We don't do that. > > No, I agree with theory of evolution, progress and > elimination-of-the-all-old-outdated-legacy-stuff, but there is still > some lower bound which still have to preserve. For instance, Riak for > very latest versions didn't officially supported anything beyond R14 > and still adding support of newest Erlang releases very accurate > (based on those what I had read on ML / GH) and currently they suggest > to use R15 instead of R16 (CouchDB does). > > On other hand RabbitMQ provides quite nice solution of this problem: > you may use older Erlang releases, but some features wouldn't works > for you. > http://www.rabbitmq.com/which-erlang.html > Since we're going to multiple repositories, rebar and completely > modular architecture, can we made some components optional depending > on available Erlang release? > > As alternative suggestion we can (and can we?) ship "the right" Erlang > release with CouchDB and eliminate this issue completely, but I'm not > sure that this idea will receive any effort... > > -- > ,,,^..^,,,
