Return-Path: Delivered-To: apmail-avro-dev-archive@www.apache.org Received: (qmail 68123 invoked from network); 19 Jul 2010 23:45:19 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 19 Jul 2010 23:45:19 -0000 Received: (qmail 67161 invoked by uid 500); 19 Jul 2010 23:45:19 -0000 Delivered-To: apmail-avro-dev-archive@avro.apache.org Received: (qmail 67078 invoked by uid 500); 19 Jul 2010 23:45:18 -0000 Mailing-List: contact dev-help@avro.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@avro.apache.org Delivered-To: mailing list dev@avro.apache.org Received: (qmail 67070 invoked by uid 99); 19 Jul 2010 23:45:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Jul 2010 23:45:18 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 19 Jul 2010 23:45:08 +0000 Received: (qmail 67940 invoked by uid 99); 19 Jul 2010 23:44:46 -0000 Received: from localhost.apache.org (HELO [192.168.168.113]) (127.0.0.1) (smtp-auth username cutting, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Jul 2010 23:44:46 +0000 Message-ID: <4C44E36D.4020506@apache.org> Date: Mon, 19 Jul 2010 16:44:45 -0700 From: Doug Cutting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Thunderbird/3.0.5 MIME-Version: 1.0 To: dev@avro.apache.org Subject: Re: 1.4.0 release soon? References: <4C44B023.4030702@apache.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 07/19/2010 03:44 PM, Bruce Mitchener wrote: > Avro C is in bad shape / a bad state. It was in the middle of some > breaking API changes (and more are needed). That's a shame. Generally we should try to keep trunk in a ready-to-release state. Long-term changes that can't be done in a patch should generally be done in a branch, not trunk. > It is probably better to look at reverting some of the changes and > just shipping what was in 1.3.x (even though the API there is not > complete and one can't actually use it for much). > > I'm on the road for the next couple of days (in Macau), so I won't be > able to do much in the short term. Will you have a chance to work on this after that? I doubt I'd roll a 1.4.0 candidate for at least a week or so, and am willing to wait a bit if improvements are imminent. Doug