Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QrElI-00068R-Fr for bitcoin-development@lists.sourceforge.net; Wed, 10 Aug 2011 19:48:20 +0000 X-ACL-Warn: Received: from mail-iy0-f171.google.com ([209.85.210.171]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QrElD-0006j4-ML for bitcoin-development@lists.sourceforge.net; Wed, 10 Aug 2011 19:48:20 +0000 Received: by iyf13 with SMTP id 13so1916076iyf.30 for ; Wed, 10 Aug 2011 12:48:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.150.69 with SMTP id z5mr3082572icv.67.1313005690129; Wed, 10 Aug 2011 12:48:10 -0700 (PDT) Received: by 10.42.226.4 with HTTP; Wed, 10 Aug 2011 12:48:10 -0700 (PDT) X-Originating-IP: [99.173.148.118] In-Reply-To: <201108101443.17015.luke@dashjr.org> References: <201108101443.17015.luke@dashjr.org> Date: Wed, 10 Aug 2011 15:48:10 -0400 Message-ID: From: Jeff Garzik To: Luke-Jr 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: 1QrElD-0006j4-ML Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Change to multiple executables? 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: Wed, 10 Aug 2011 19:48:20 -0000 On Wed, Aug 10, 2011 at 2:43 PM, Luke-Jr wrote: > On Wednesday, August 10, 2011 1:45:42 PM John Smith wrote: >> 0.3.x -> small, compatible changes, bugfixes, like now >> 0.4.x -> trunk, more impactful changes, refactorings, eventual major >> release > > It seems there's room for some kind of "experimental" branch as well, > including features that might not make it into any stable release (due to lack > of use/interest or whatever). In kernel land there exists "linux-next" Stephen Rothwell maintains a tree that is linux -tip, plus a list of trees & branches to pull from various individual developers. For example, linux-next pulls my SATA tree from libata-dev.git branch NEXT. Each developer is expected to publish changes they feel are ready for upstream. Developers are expected to "play nicely" and coordinate amongst themselves when two trees include conflicting changes. Trivial merge conflicts are handled by Stephen Rothwell, who does merging, build testing and such of the final set-of-N-trees result. More difficult merge conflicts are coordinated by the developers themselves, who work together to create a temporary "merge tree" that is then pulled by the linux-next maintainer. linux-next is the always moving, regenerated daily target where developers stage [in their opinion] upstream-ready changes. Thus Linus's linux.git development process really looks like the following, when linux-next is included in the picture: 1. Version X-1 is released, on day 0. 2. Merge window for version X opens, on day 0. 3. Linus pulls all changes that have seen testing in linux-next, over the -rc window (step #6, below) 4. Merge window closes, on day 7. 5. Version X-rc1 is released, on day 7. 6. Only bug fixes are accepted now (hopefully seen at least 24 hours of testing in linux-next, unless urgency demands otherwise). All new development is done in developer trees and branches, and is automatically published nightly in linux-next. 7. Version X is released, on day 90. Thus "upstream" stays almost constantly stable, except for the short 1-week merge window period, and linux-next comprises the rolling "development version" where new changes are staged. Note the subtle but important distinction between this and maintaining a strict 'bugfix' and 'development' branch system like John Smith described. The underlying linux-next dependent trees may be rebased at any time, and so linux-next is constantly regenerated, rather than being a cumulative history of choatic development. Major changes can and will be staged, de-staged, and re-staged during development, and maintaining a strict "official development branch" methodology is less flexible. Here is an example linux-next report. Stephen sends one, daily, with each linux-next tree generated: http://marc.info/?l=linux-next&m=131295044704945&w=2 As it applies to bitcoin, this "bitcoin-next" approach may simply be layered on top of the current methodology. All it requires is a volunteer who maintains this tree-of-trees, and wha-la: bitcoin has a development branch. -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti.com