Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4302C7277 for ; Thu, 6 Oct 2011 18:10:35 +0000 (UTC) Received: (qmail 9200 invoked by uid 500); 6 Oct 2011 18:10:34 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 9167 invoked by uid 500); 6 Oct 2011 18:10:34 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 9158 invoked by uid 99); 6 Oct 2011 18:10:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Oct 2011 18:10:34 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of fdmanana@gmail.com designates 209.85.220.180 as permitted sender) Received: from [209.85.220.180] (HELO mail-vx0-f180.google.com) (209.85.220.180) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Oct 2011 18:10:28 +0000 Received: by vcbf11 with SMTP id f11so3873338vcb.11 for ; Thu, 06 Oct 2011 11:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=LX8Ola872UA5bYy3D80lECOb6LeUn1+SIggUX2LXAiw=; b=XALzH6KUFtdGRYFqCrPR6E9CPWsrrrczJPTCr7CsCJugwsiNxXkNPgCKyjW35PbcCj cbRUu1VJu/CVifr+3Gd3CiusiUwTmUO8fppmSH/L538GDJuxSzoRKuo6+/X7ubGPXk39 Z6nuMkO3bXUCfwWTofLQ+SA6+uCD03zCyKxIw= MIME-Version: 1.0 Received: by 10.68.24.35 with SMTP id r3mr7062257pbf.116.1317924607188; Thu, 06 Oct 2011 11:10:07 -0700 (PDT) Sender: fdmanana@gmail.com Received: by 10.142.242.6 with HTTP; Thu, 6 Oct 2011 11:10:06 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Oct 2011 19:10:06 +0100 X-Google-Sender-Auth: oTBz7g5lf-9WiX65X-tg7b5S350 Message-ID: Subject: Re: CouchDB 1.1.1 From: Filipe David Manana To: dev@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 6, 2011 at 6:59 PM, Robert Newson wrote: > does the newer erlang-oauth break anything? Not that I know of. > > On 6 October 2011 18:52, Filipe David Manana wrote: >> On Thu, Oct 6, 2011 at 6:23 PM, Robert Newson 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 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 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 wr= ote: >>>>>>> On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson = 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 presen= t in >>>>>>>> 1.1.0 so will not be (officially) missed. >>>>>>>> >>>>>>>> The place for a breaking change of this magnitude is 1.2, not a mi= nor >>>>>>>> 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 = wrote: >>>>>>>>> Yes, its release blocking. >>>>>>>>> >>>>>>>>> On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson 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 t= his >>>>>>>>>> file up to date when commit bugfixes or add features?). I'd appr= eciate >>>>>>>>>> everyone giving it a look over before I start to build the relea= se >>>>>>>>>> artifact. >>>>>>>>>> >>>>>>>>>> I believe there's an outstanding issue (not present in JIRA) aro= und >>>>>>>>>> javascript function evaluation? Can someone confirm that it's re= lease >>>>>>>>>> blocking? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> B. >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> >> >> >> >> -- >> Filipe David Manana, >> >> "Reasonable men adapt themselves to the world. >> =C2=A0Unreasonable men adapt the world to themselves. >> =C2=A0That's why all progress depends on unreasonable men." >> > --=20 Filipe David Manana, "Reasonable men adapt themselves to the world. =C2=A0Unreasonable men adapt the world to themselves. =C2=A0That's why all progress depends on unreasonable men."