On Thu, Oct 6, 2011 at 6:23 PM, Robert Newson <[email protected]> wrote: > If there are no objections, I'm going to build the first 1.1.1 > candidate in the morning and start a new thread for the release.
As pointed out in 2 other related threads, we have some compilation warnings about functions that will no longer exist in OTP R15 (to be released by the end of this year): /opt/r14b03/bin/erlc +debug_info oauth_http.erl ./oauth_http.erl:13: Warning: http:request/4 is deprecated and will be removed in R15B; use httpc:request/4 /opt/r14b03/bin/erlc +debug_info oauth_plaintext.erl /opt/r14b03/bin/erlc +debug_info oauth_rsa_sha1.erl ./oauth_rsa_sha1.erl:9: Warning: public_key:pem_to_der/1: deprecated (will be removed in R15A); use file:read_file/1 and public_key:pem_decode/1 ./oauth_rsa_sha1.erl:10: Warning: public_key:decode_private_key/1 is deprecated and will be removed in R15A; use public_key:pem_entry_decode/1 ./oauth_rsa_sha1.erl:22: Warning: public_key:pem_to_der/1: deprecated (will be removed in R15A); use file:read_file/1 and public_key:pem_decode/1 /opt/r14b03/bin/erlc +debug_info oauth_unix.erl The ones regarding public_key concern me, as it will break the OAuth authentication handler. I see 2 solutions: 1) upgrade erlang-oauth to the same version we have in trunk/1.2.x (doesn't produce these warnings) 2) modify the erlang-oauth in 1.1.x and use try catches where the catch would call the equivalent versions in R14/R15 (these new functions don't exist in R13B03 for example) Naturally, I would prefer 1) The warnings about http:request can be ignored I think, as in Couch we don't use any codepath that will execute the deprecated function > > B. > > On 6 October 2011 12:05, Robert Newson <[email protected]> wrote: >> Thanks all, I've pushed the change to 1.1.x. make check and futon all >> pass; review would still be nice. :) I simply reverted the two >> commits. >> >> B. >> >> On 6 October 2011 12:02, Jan Lehnardt <[email protected]> wrote: >>> >>> On Oct 6, 2011, at 10:30 , Robert Newson wrote: >>> >>>> There is no build of 1.1.1 on Ubuntu 11.x that will work as well as >>>> 1.1.0, so I think it's correct that it cannot build under those >>>> conditions. >>>> >>>> Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and >>>> then focus on getting 1.2 out with 1.8.5 support (and "BREAKING >>>> CHANGES"). >>>> >>>> I vote +1 to removing 1.8.5 support and the paren hack from 1.1.x. >>> >>> +1 >>> >>> Cheers >>> Jan >>> -- >>> >>> >>>> >>>> B. >>>> >>>> On 6 October 2011 09:25, Paul Davis <[email protected]> wrote: >>>>> On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson <[email protected]> wrote: >>>>>> All, >>>>>> >>>>>> Paul Davis has researched the issue and it seems intractable. >>>>>> >>>>>> I would like to remove 1.8.5 support from 1.1.1. It was not present in >>>>>> 1.1.0 so will not be (officially) missed. >>>>>> >>>>>> The place for a breaking change of this magnitude is 1.2, not a minor >>>>>> bug fix release. >>>>>> >>>>>> Thoughts? >>>>>> B. >>>>>> >>>>> >>>>> +1 on removing the paren hack for sure. >>>>> >>>>> Not sure about removing 1.8.5 support completely. On the one hand, it >>>>> would prevent breakage because people couldn't link against the >>>>> breaking SM. On the other hand, it prevents people from linking >>>>> against 1.8.5 which means it won't build on Ubuntu 11.x. >>>>> >>>>> Unless someone comes up with a magic option I'd say put it to an >>>>> informal vote so that I can blame someone else. >>>>> >>>>>> On 5 October 2011 18:25, Paul Davis <[email protected]> wrote: >>>>>>> Yes, its release blocking. >>>>>>> >>>>>>> On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson <[email protected]> >>>>>>> wrote: >>>>>>>> All, >>>>>>>> >>>>>>>> I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to >>>>>>>> include everything that was missing (Sidenote: Can we all keep this >>>>>>>> file up to date when commit bugfixes or add features?). I'd appreciate >>>>>>>> everyone giving it a look over before I start to build the release >>>>>>>> artifact. >>>>>>>> >>>>>>>> I believe there's an outstanding issue (not present in JIRA) around >>>>>>>> javascript function evaluation? Can someone confirm that it's release >>>>>>>> blocking? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> B. >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >>> >> > -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
