public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Luke-Jr" <luke@dashjr.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] 0.4.x stable branch
Date: Mon, 19 Sep 2011 11:00:54 -0400	[thread overview]
Message-ID: <201109191100.58100.luke@dashjr.org> (raw)
In-Reply-To: <CABsx9T2FBNv26E4LHmi9GVfi1HLR1wR__qGp1_gjco8rwN0L4Q@mail.gmail.com>

On Monday, September 19, 2011 8:49:08 AM Gavin Andresen wrote:
> On Sun, Sep 18, 2011 at 7:30 PM, Luke-Jr <luke@dashjr.org> wrote:
> > If we prepare the git repository + tags, would you guys be
> > willing to make the actual release builds + source, and/or post such on
> > the websites you administrate?
> > Luke and various others in #bitcoin-stable
> 
> My initial reaction is no. Testing and bug-fixing is the bottleneck
> for making core bitcoin better, and maintaining two release lines
> won't make that better.
> 
> I also think that until we get to a "1.0" that we can all agree is
> ready for everybody AND their grandma to use, using the word "stable"
> would be dishonest.

The problem with the current development model is that bugfixes are done 
alongside improvements, and code changes *always* have the potential to 
introduce new bugs, no matter how careful anyone is. So to stay on top of 
bugfixes right now implies risking new bugs being introduced. What good is 
getting one bug fixed, if it comes with 20 new yet-to-be-discovered bugs?

For example, 0.3.20.2 was the last version if bitcoind before people started 
experiencing random (albeit rare) deadlocks. However, there have been many 
bugfixes since then. Since there is no stable branch, someone who wishes to 
get those bugfixes is forced to either create their own stable branch from 
scratch, or risk getting all the new bugs introduced in the latest version 
(most of which are unknown at this time).

On the other hand, a stable 0.4.x branch can provide people with upgrades 
which they know make only the minimal changes required to fix bugs with a much 
smaller risk of new bugs being introduced (not only are there fewer changes, 
but bugfixes tend to also be less invasive changes). While there are arguably 
still various "must-have" features missing from 0.4, having a stable branch 
also allows people to maintain a stable+<feature I need> branch with greater 
ease too.



  parent reply	other threads:[~2011-09-19 15:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-18 23:30 [Bitcoin-development] 0.4.x stable branch Luke-Jr
2011-09-19 12:49 ` Gavin Andresen
2011-09-19 13:03   ` Gregory Maxwell
2011-09-19 13:48   ` Amir Taaki
2011-09-19 15:00   ` Luke-Jr [this message]
2011-09-19 15:06     ` Gregory Maxwell
2011-09-20  4:41     ` theymos
2011-09-20 19:10 ` Jeff Garzik
2011-09-20 20:37   ` Luke-Jr
2011-09-21 14:24     ` Alex Waters

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=201109191100.58100.luke@dashjr.org \
    --to=luke@dashjr.org \
    --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