On 8 Dec 2010, at 00:05, Robert Newson wrote: > Not to hijack the thread but the Mochiweb upgrade also makes eunit a > build dependency which has caused issues on Debian installs (eunit > being a separate and optional package).
Didn't you propose a patch to mochiweb that makes eunit build-optional? Cheers Jan -- > > On Tue, Dec 7, 2010 at 11:03 PM, Robert Newson <[email protected]> > wrote: >> +1 for R13B04. >> >> On Tue, Dec 7, 2010 at 10:53 PM, Paul Davis <[email protected]> >> wrote: >>> On Tue, Dec 7, 2010 at 5:46 PM, Paul Davis <[email protected]> >>> wrote: >>>> On Tue, Dec 7, 2010 at 5:43 PM, Adam Kocoloski <[email protected]> wrote: >>>>> On Dec 7, 2010, at 5:40 PM, Paul Davis wrote: >>>>> >>>>>> On Tue, Dec 7, 2010 at 5:38 PM, Adam Kocoloski <[email protected]> >>>>>> wrote: >>>>>>> Hi, the mochiweb we're shipping in 1.1.0 has abandoned support for >>>>>>> R12B05, so we should revisit our minimum required Erlang version. Do >>>>>>> we have a compelling reason for supporting anything below R13B04? That >>>>>>> release introduces support for recursive type specifications, which are >>>>>>> useful when describing revision trees and JSON objects to dialyzer. >>>>>>> >>>>>>> Regards, Adam >>>>>> >>>>>> +1 for R13something. >>>>> >>>>> Paul, is there a NIF-based argument for a particular R13 release? I know >>>>> we don't use NIFs in 1.1.x, but it'd be nice to limit the number of times >>>>> we have to bump. >>>>> >>>>> Adam >>>> >>>> There's nothing major that I remember in the R13 series. Maybe a few >>>> bug fixes or something, but I'd have to look. >>>> >>>> The major NIF jump was with R14. For instance, integrating Emonk requires >>>> R14. >>>> >>>> Also, NIF's are awesome. >>>> >>> >>> I stand corrected. Out of curiosity I went back and checked the >>> progression of NIF support. Turns out they're not even available until >>> R13B03. For some reason I thought the first version was in the last of >>> the R12's. >>> >>> Also, in R13B04 there are some noticeable upgrades to things like NIF >>> function signatures and other bits that would be backwards >>> incompatible (also, no one uses the version from R13B03 anymore, so if >>> we wanted to backport something it'd be a major breakage). >>> >>> So I revise my statement, I'd vote for R13B04 as the minimum. Also, it >>> has the nice symmetry of relying on the latest R$(MAJOR)B04 Erlang VM >>> which I declare to be the optimum balance between new features and >>> stability. >>> >>
