On Thu, Jan 23, 2014 at 11: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. > I personally would question it in the case of python 2.5. But that's another question. In that case the reason I am asking this is because (like python 2.5 somehow), we are speaking to support a version that won't have anymore fixes. Even security fixes. What I want to list are the blocking items. If they have been fixed in an Erlang version then at some point we can drop support for an old and unmaintained version. That's the main point. The fact that some companies are still using an old version, is not a valid reason to support it. There can have many other reason, not rational, to support a version. Also not supporting it doesn't mean removing the code to support it immediately, it can just be deprecated for 1-2 or more versions. Knowing when it can be deprecated or what should prevent any deprecation is the key. > > 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 I said many times, that a lot of developer are actually jumping from r14 support to anything greater. To be clear I don't think the proposition to keep an old release as outrageous. I am more interested by facts. I am more interested to know the reasons that could trigger a switch. (And other than "we are using that, so you should"). > > 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. > Well some optimisations could already be done. But don't get me wrong as well, the thing I really want is that we continue to support a version for valid reasons (and again, other than "we are using X"). Listing them is just a way to check if they are still valid on the time of the next release. - benoit
