couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: Git Repository Creation
Date Wed, 22 Jan 2014 10:49:58 GMT
On Wed, Jan 22, 2014 at 11:35 AM, Alexander Shorin <> wrote:

> On Wed, Jan 22, 2014 at 2:19 PM, Benoit Chesneau <>
> wrote:
> > On Tue, Jan 21, 2014 at 3:25 PM, Robert Samuel Newson <
> >
> >> 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.

- benoit

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message