Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of brane@wandisco.com designates
 74.125.83.49 as permitted sender)
Message-ID: <51B9E53E.80408@wandisco.com>
Date: Thu, 13 Jun 2013 17:29:02 +0200
From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@wandisco.com>
Organization: WANdisco
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: dev@subversion.apache.org
Subject: Re: Proposal for reducing Subversion's lengthy (and unpredictable)
 release cycles.
References: <51B9C8AB.9090203@collab.net>
 <20130613134328.GJ2774@tarsus.local2>
In-Reply-To: <20130613134328.GJ2774@tarsus.local2>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 13.06.2013 15:43, Daniel Shahaf wrote:
> C. Michael Pilato wrote on Thu, Jun 13, 2013 at 15:27:07 +0200:
>> In the interest of serving our user base, we are proposing that each release
>> live on the trunk for at most nine months.  The first six months of this
>> period are open to new features.  In the first three months of the new
>> feature period, large, destabilizing features will be accepted (under the
>> provision that the feature itself is arguably “complete”, which seemingly
>> implies that it was developed on a feature branch maintained with routine
>> sync merges.
> Or, where possible, developed on trunk within #ifdef THAT_FEATURE tags,
> with -DTHAT_FEATURE being disabled by default.

I'd have thought so too, but in fact, we're supposed to be writing a
version control system, so avoiding using branches for their primary
purpose (i.e., isolating lines of development) seems kind of
counter-productive.

Quite frankly, I'm sometimes just a bit bored by all the conditional
blocks in our code.

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com