couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: Git Repository Creation
Date Wed, 22 Jan 2014 11:09:06 GMT
On Wed, Jan 22, 2014 at 2:49 PM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> On Wed, Jan 22, 2014 at 11:35 AM, Alexander Shorin <kxepal@gmail.com> wrote:
>
>> On Wed, Jan 22, 2014 at 2:19 PM, Benoit Chesneau <bchesneau@gmail.com>
>> wrote:
>> > On Tue, Jan 21, 2014 at 3:25 PM, Robert Samuel Newson <
>> rnewson@apache.org>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...

--
,,,^..^,,,

Mime
View raw message