couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filipe David Manana <fdman...@apache.org>
Subject Re: CouchDB 1.1.1
Date Thu, 06 Oct 2011 17:52:10 GMT
On Thu, Oct 6, 2011 at 6:23 PM, Robert Newson <rnewson@apache.org> 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 <rnewson@apache.org> 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 <jan@apache.org> 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 <paul.joseph.davis@gmail.com> wrote:
>>>>> On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson <rnewson@apache.org>
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 <paul.joseph.davis@gmail.com>
wrote:
>>>>>>> Yes, its release blocking.
>>>>>>>
>>>>>>> On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson <rnewson@apache.org>
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."

Mime
View raw message