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
