[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.

From: Greg Stein <gstein_at_gmail.com>
Date: Thu, 13 Jun 2013 14:00:09 -0400

On Thu, Jun 13, 2013 at 11:29 AM, Branko Čibej <brane_at_wandisco.com> wrote:
> 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.

People don't pay attention to branches. That has been empirically proven.

If you want eyeballs, then you code on trunk.

(and that seems fine, as long as your code does not *destabilize*
trunk; with the "new rule", it also seems that any new "feature" needs
to stay hidden until "ready", for some definition of "ready")

Cheers,
-g
Received on 2013-06-13 20:00:49 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.