From: Jeff Garzik <jgarzik@exmulti.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] 0.3.24
Date: Fri, 1 Jul 2011 20:37:35 -0400 [thread overview]
Message-ID: <BANLkTi=zG4o5igBFX=4Yg340B0QGF42RBQ@mail.gmail.com> (raw)
In-Reply-To: <BANLkTinqcaDMci-YmYHpDd1sZ_RT9pEOvw@mail.gmail.com>
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
next prev parent reply other threads:[~2011-07-02 0:37 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-01 0:07 [Bitcoin-development] 0.3.24 Matt Corallo
2011-07-01 2:07 ` Gregory Maxwell
2011-07-01 2:44 ` Douglas Huff
2011-07-01 12:41 ` Douglas Huff
2011-07-01 8:00 ` Pieter Wuille
2011-07-01 8:39 ` Jeff Garzik
2011-07-01 12:31 ` Gavin Andresen
2011-07-01 12:40 ` Matt Corallo
2011-07-01 15:06 ` Gavin Andresen
2011-07-01 16:35 ` jan
2011-07-01 16:47 ` Robert McKay
2011-07-01 17:47 ` Douglas Huff
2011-07-01 17:50 ` Matt Corallo
2011-07-01 17:52 ` Douglas Huff
2011-07-01 22:03 ` Matt Corallo
2011-07-01 22:07 ` Douglas Huff
2011-07-01 17:59 ` Gregory Maxwell
2011-07-01 23:42 ` Jeff Garzik
2011-07-02 0:37 ` Jeff Garzik [this message]
2011-07-02 0:46 ` Matt Corallo
2011-07-02 0:51 ` Gregory Maxwell
2011-07-02 1:05 ` Douglas Huff
2011-07-02 1:12 ` Matt Corallo
2011-07-02 2:05 ` Gavin Andresen
2011-07-02 21:07 ` Jeff Garzik
2011-07-03 1:58 ` Matt Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='BANLkTi=zG4o5igBFX=4Yg340B0QGF42RBQ@mail.gmail.com' \
--to=jgarzik@exmulti.com \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=gavinandresen@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox