righto.
On Wed, Dec 8, 2010 at 12:53 AM, Paul Davis <[email protected]> wrote: > I vote for just deleting the eunit bits in our packaged version. Its > not like we use them. And I'd rather delete the eunit code rather than > grab it as a dependency (and then deal with figuring out what to do > when there's an installed version or not or should be but a distro has > stripped it out). > > On Tue, Dec 7, 2010 at 6:28 PM, Robert Newson <[email protected]> wrote: >> I did and it was rewritten upstream >> (https://github.com/mochi/mochiweb/commit/e8156a1c44d054f1f6e9396c828751ed22418d7f). >> >> It's after the release we have so we have a few options; >> >> 1) Upgrade to a newer version. >> 2) Backport the patch. >> 3) Add eunit dependency to autotools. >> >> I vote for 3 for 1.1 and then upgrade and revert that when mochiweb >> makes a release with the fix. >> >> B. >> >> On Tue, Dec 7, 2010 at 11:11 PM, Jan Lehnardt <[email protected]> wrote: >>> >>> 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. >>>>>> >>>>> >>> >>> >> >
