1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1R5fLN-0000el-Gj
for bitcoin-development@lists.sourceforge.net;
Mon, 19 Sep 2011 15:01:13 +0000
X-ACL-Warn:
Received: from zinan.dashjr.org ([173.242.112.54])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1R5fLJ-0000Ay-Eh for bitcoin-development@lists.sourceforge.net;
Mon, 19 Sep 2011 15:01:13 +0000
Received: from ishibashi.localnet (fl-184-4-160-40.dhcp.embarqhsd.net
[184.4.160.40]) (Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id D2D11204025;
Mon, 19 Sep 2011 15:01:03 +0000 (UTC)
From: "Luke-Jr" <luke@dashjr.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Date: Mon, 19 Sep 2011 11:00:54 -0400
User-Agent: KMail/1.13.7 (Linux/2.6.39-gentoo; KDE/4.6.5; x86_64; ; )
References: <201109181930.59565.luke@dashjr.org>
<CABsx9T2FBNv26E4LHmi9GVfi1HLR1wR__qGp1_gjco8rwN0L4Q@mail.gmail.com>
In-Reply-To: <CABsx9T2FBNv26E4LHmi9GVfi1HLR1wR__qGp1_gjco8rwN0L4Q@mail.gmail.com>
X-PGP-Key-Fingerprint: CE5A D56A 36CC 69FA E7D2 3558 665F C11D D53E 9583
X-PGP-Key-ID: 665FC11DD53E9583
X-PGP-Keyserver: x-hkp://subkeys.pgp.net
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201109191100.58100.luke@dashjr.org>
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1R5fLJ-0000Ay-Eh
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] 0.4.x stable branch
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 19 Sep 2011 15:01:13 -0000
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.
|
