Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2011-07-01 🗒️ Summary of this message: Discussion on ...
📅 Original date posted:2011-07-01
🗒️ Summary of this message: Discussion on releasing Bitcoin version 0.3.24 with cherry-picked fixes or current upstream with CWallet testing before 0.4 release.
📝 Original message:Personally, I have little preference, sipa and gmaxwell fall on the side
of cherry-pick, but I think it might be good to do a broad-base test of
CWallet in 0.3.24 so potential bugs can be found in it before crypto and
0.4. In either case, I dont think we should spend too much time as this
is just a minor update release, just get it out the door so we can focus
on 0.4 (hopefully) without interruption.
Matt
On Fri, 2011-07-01 at 20:37 -0400, Jeff Garzik wrote:
> 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...
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110702/88fd5bb9/attachment.sig>;
🗒️ Summary of this message: Discussion on releasing Bitcoin version 0.3.24 with cherry-picked fixes or current upstream with CWallet testing before 0.4 release.
📝 Original message:Personally, I have little preference, sipa and gmaxwell fall on the side
of cherry-pick, but I think it might be good to do a broad-base test of
CWallet in 0.3.24 so potential bugs can be found in it before crypto and
0.4. In either case, I dont think we should spend too much time as this
is just a minor update release, just get it out the door so we can focus
on 0.4 (hopefully) without interruption.
Matt
On Fri, 2011-07-01 at 20:37 -0400, Jeff Garzik wrote:
> 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...
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110702/88fd5bb9/attachment.sig>;