couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Git Repository Creation
Date Thu, 23 Jan 2014 11:09:44 GMT
On Thu, Jan 23, 2014 at 11:48 AM, Paul Davis <paul.joseph.davis@gmail.com>wrote:

> I misspoke on records. Obviously meant maps or frames or whatever is
> they're calling them now.
>

I am not sure that frames will be part of R17. Not sure about the status of
dirty schedulers as ell. maps and named functions will be certainly a nice
thing to use.

- benoit



>
> On Thu, Jan 23, 2014 at 2:47 AM, Paul Davis <paul.joseph.davis@gmail.com>
> wrote:
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message