subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.
Date Thu, 13 Jun 2013 18:00:09 GMT
On Thu, Jun 13, 2013 at 11:29 AM, Branko Čibej <> 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")


View raw message