From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QcoDO-0004EU-0S for bitcoin-development@lists.sourceforge.net; Sat, 02 Jul 2011 00:37:42 +0000 X-ACL-Warn: Received: from mail-iy0-f175.google.com ([209.85.210.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QcoDM-0006N9-IL for bitcoin-development@lists.sourceforge.net; Sat, 02 Jul 2011 00:37:41 +0000 Received: by iym10 with SMTP id 10so4706182iym.34 for ; Fri, 01 Jul 2011 17:37:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.135 with SMTP id n7mr3178048ibi.189.1309567055189; Fri, 01 Jul 2011 17:37:35 -0700 (PDT) Received: by 10.231.37.3 with HTTP; Fri, 1 Jul 2011 17:37:35 -0700 (PDT) X-Originating-IP: [99.173.148.118] In-Reply-To: References: <1309478838.3689.25.camel@Desktop666> <20110701080042.GA657@ulyssis.org> <1309524016.2541.0.camel@Desktop666> Date: Fri, 1 Jul 2011 20:37:35 -0400 Message-ID: From: Jeff Garzik To: Gavin Andresen Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1QcoDM-0006N9-IL Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] 0.3.24 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 00:37:42 -0000 Hum, it sounds like there was some misunderstanding, on my part at least. On IRC, people are talking about a cherry-picked release, basically 0.3.23 + a couple specific fixes, rather than what is current in upstream git. I had assumed people meant releasing current git + some specific fixes not yet in git. Wearing the Release Mangler hat, cherry-picked branches have a few disadvantages: * you're throwing away the testing people have done on upstream git * the new branch would have zero testing, as most people have been testing 0.3.23 or upstream git * it would be a dead-end branch, never touched after release. bug reports for such a release might not necessarily be applicable to last version or current upstream or anywhere in between. That is the convention wisdom, anyway. But to paraphrase Pirates of the Caribbean, release management rules aren't really rules, they're more like... guidelines. :) The cherry-picked 0.3.24 release, according to IRC wisdom, wouldn't have to worry about shipping CWallet, which needs a fix or two from https://github.com/bitcoin/bitcoin/pull/358 I can live with, and roll a release for, either (a) 0.3.23 + select fixes or (b) current upstream + pull #358. My preference is (b), but this is a community and Holy Alpaca decision, not just a call I will make on my own. Comments welcome... -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti.com