Let’s not forget that R14B02 is also totally broken (ets tables get scrambled due to a 32/64 bit error).
To summarize why we don’t trust versions other than R14B01 is really just to say that there are many releases since with known and severe problems, there’s clearly not enough test coverage in the release procedure to cover some fairly basic stuff, and bad releases continue to happen. How *can* we build confidence in them by any mechanism other than running them under heavy and varied load for long periods of time? Cloudant has done that (in spades) for R14B01. There are two bugs in R14B01 that we do encounter, however. 1) Another 32/64 bit oops causes the vm to attempt to allocate huge amounts of ram (terabytes, or more) if it ever tries to allocate more than 2gib of ram at once. When this happens, the vm dies and is restarted. It’s annoying, but infrequent. 2) Sometimes when closing a file, the underlying file descriptor is *not* closed, though the erlang process exits. This is rare but still quite annoying. It would great if there was a release which introduces no new bugs and fixes those two. I just can’t identify one. The frames in R17 will be a *huge* reason to move forward, assuming stability and non-brokenness. CouchDB is very promiscuous at passing records between modules and BigCouch does so between erlang nodes. This makes a hot code upgrade really tricky. Frames (or Maps, I think is the new name) would avoid that, after another painful record-to-maps upgrade. We’d be able to add new fields without breaking inter-process or inter-node message passing while modules are upgrading. Summary: R14B01 is not broken (well, its bugs are known and not severe) and nothing since it’s as known not to be broken. Whether the Erlang/OTP team support a release is less interesting to me in contexts like this one where we don’t need any. B. On 23 Jan 2014, at 11:09, Benoit Chesneau <[email protected]> wrote: > 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. >>
