couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Git Repository Creation
Date Thu, 23 Jan 2014 10:47:34 GMT
On Thu, Jan 23, 2014 at 2:11 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> On Thu, Jan 23, 2014 at 10:30 AM, Paul Davis <paul.joseph.davis@gmail.com>wrote:
>
>> On Thu, Jan 23, 2014 at 1:14 AM, Benoit Chesneau <bchesneau@gmail.com>
>> wrote:
>> > On Thu, Jan 23, 2014 at 8:07 AM, Robert Samuel Newson <
>> rnewson@apache.org>wrote:
>> >
>> >>
>> >> Ditto, can’t think of a thing worth having post-R14 to take the leap
>> given
>> >> the numerous broken releases. I had forgotten that monitoring was
>> broken in
>> >> R16B01. Good grief.
>> >>
>> >
>> >
>> > Probably. So again what are **exactly** these grief. Saying something is
>> > broken is fine. But is there any openened issue on Erlang side? Also I
>> > would be interested by a description of the problem and how to  reproduce
>> > it. Something we can put on this check list.
>> >
>> > - benoit
>>
>> Bob was replying to my email that linked to the bug report here:
>>
>> http://erlang.org/pipermail/erlang-bugs/2013-July/003670.html
>>
>> Mayhaps you missed the original?
>>
>
> Well, the point is that we still not have an exact list of the issues you
> seems to see in later releases. . Each versions of Erlang has its own
> grief, R14B until 04 certainly had its own bugs too. R14B01 for example had
> some issues with the file driver if I remember and other things I can't
> remember now (that's really old).
>
> Having an exact list list somewhere that explain why we are supporting such
> an old release is good for many reasons:
>
> - make sure we can check again new release if we still need to support it
> - explain to users why we are supporting it
> - prepare for future deprecations
> - ...
>
> Also we should make sure that the issue are opened in the Erlang bug
> tracker (having the tickets number in that list could help) . If we have to
> support R14 an unmaintained, 2 years old,  unsupported release that tend to
> be removed from other libs, then we should know exactly why and we should
> try to fix it upstream. Keeping an old version is not that good and will
> make it more and more difficult to use latest new features. (like the
> latest changes in the binary API, crypto, ...).
>
> - benoit

I'm confused why you're asking for a itemized argument for supporting
R14. That'd be like asking why a Python project supports the 2.5
interpreter. I even dislike supporting 2.5 personally yet I wouldn't
think to question a project that makes that decision.

This isn't a "I won't use R16B03 because of tickets X, Y, and Z" issue
so much as "Holy crap they broke monitor delivery! Do you reckon they
fixed it without breaking anything else?" Beyond that there's also the
wider Erlang community. The developers of another well known Erlang
database are only on R15 so *supporting* R14 doesn't seem like an
outrageous proposition.

And don't get me wrong, I'm all for ensuring that CouchDB works on
newer versions of the VM. I just don't see what's so great about newer
VMs that we need to drop support for R14. You've mentioned new binary
API and crypto but what about those things would we want to use that
force us to drop R14? Earlier James mentioned SSL support, but is
there a backwards incompatible change there or is it just "SSL works
better" thing?

I would understand if it were something like maps (or records or w/e)
in R17 where we go through and do radical things to the code base.
Making that switch will definitely require us to drop pre-R17 support
and we may decide to do that. But beyond that I don't know of anything
that is so awesome that'd be worth it to drop support for an entire
major version of the VM.

Mime
View raw message