[wp-hackers] User Feedback and Testing

[John Joseph Bachir]

On Sun, 1 Jan 2006, Ryan Boren wrote:

> Right now, trunk is the bugfix branch for 2.0.  Only 2.0 fixes are going 
> in.  There is no feature development going on right now so no need for a 
> branch.

But there _could_ be feature development. There are probably a good 
handful of developers with spare cycles who don't have any bugs to squash 
and would like to work on what will become 2.1 (or whatever is released in 
6 months).

For WordPress this is a particular problem because no one has any idea 
when the next bugfix release will be, which discourages developers from 
even thinking about new features, and certainly from writing them. Who 
wants to work on a new feature only to have the changes sit on their dev 
meachine for a few months (actually, for a completely unknown time period) 
until the next bugfix version is suddenly released? I know that patches 
can be submitted and flagged as 2.1, but that ticket is going to sit 
around for a few weeks or months as well, where the developer misses out 
on feedback from other developers and testers, and also from seeing if the 
new feature interacts well with other features that other developers are 
developing.

For some things this could be solved by making feature branches, but since 
most of the new features in question are relatively small and iterative, 
the administrative and social overhead of created a branch for each little 
feature addition would not be worth it. Or there could be a new_features 
branch where all the new features went... but that's the point of having a 
release branch and an active trunk in the first place.

> If I branch now I have to keep trunk and the branch in sync. No point in 
> that.

The traditional way to do this (from my own experience and reading anyway 
-- other folks please chime in with other models that they have used) is a 
2.01 branch, which would receive all the bugfixes and none of the 
features. New features would go into trunk. If you want to merge changes 
to the 2.01 branch into trunk, that's fine, although probably not 
necessary since the bugs at this point will be nuanced and rare. Changes 
to trunk would of course never be merged into 2.01.

So after making the branch, no merging needs to be done until 2.01 is 
released. At this point, the 2.01 branch will be [1] copied into a 2.01 
tag [2] merged into trunk [3] deleted.

John
--
http://lyceum.ibiblio.or