On Thu, Jan 23, 2014 at 11:48 AM, Paul Davis <[email protected]>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 <[email protected]> > wrote: > > On Thu, Jan 23, 2014 at 2:11 AM, Benoit Chesneau <[email protected]> > wrote: > >> On Thu, Jan 23, 2014 at 10:30 AM, Paul Davis < > [email protected]>wrote: > >> > >>> On Thu, Jan 23, 2014 at 1:14 AM, Benoit Chesneau <[email protected]> > >>> wrote: > >>> > On Thu, Jan 23, 2014 at 8:07 AM, Robert Samuel Newson < > >>> [email protected]>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. >
