I misspoke on records. Obviously meant maps or frames or whatever is they're calling them now.
On Thu, Jan 23, 2014 at 2:47 AM, Paul Davis <paul.joseph.da...@gmail.com> wrote: > On Thu, Jan 23, 2014 at 2:11 AM, Benoit Chesneau <bchesn...@gmail.com> wrote: >> On Thu, Jan 23, 2014 at 10:30 AM, Paul Davis >> <paul.joseph.da...@gmail.com>wrote: >> >>> On Thu, Jan 23, 2014 at 1:14 AM, Benoit Chesneau <bchesn...@gmail.com> >>> wrote: >>> > On Thu, Jan 23, 2014 at 8:07 AM, Robert Samuel Newson < >>> rnew...@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.
