I've done some initial analysis of the status of "master" and it seems to be reasonable, but there are half baked features that blocks users from installing it (e.g. crypto stuff not integrated into install).  These features are now tracked under one common issue.

In my opinion, owners of these features should go in and fix them.  If we can't release off master in the near future, I'll propose that we consider such branch as another vNext, and branch a new master out of master-1.2.x.

We need to get quickly in a state where we have a healthy branch to release 1.3.0 from and have an easy way to merge fixes between a healthy 1.4 and a healthy 1.3.

On Fri, Mar 30, 2012 at 2:32 PM, John Reese <john@noswap.com> wrote:
On Fri, Mar 30, 2012 at 2:29 PM, Victor Boctor <victor@futureware.com.au> wrote:
> Good points.
> 1. I expect each developer to do the necessary testing before checking in.
> 2. In case some bugs slip through, we can revert the change rather than hold
> off the release.
> 3. If a feature is done, but we find a corner / small issue (like what
> happens when upload of 1 of N files fails), maybe we can consider the issue
> done, and open a follow up bug to fix this specific case.
> 4. If a feature is almost done, then no need to rush it, knowing that there
> is another train to catch next month.
> Thoughts are welcome.

If we're going to strictly time-based releases (similar to Firefox and
Chrome), then I think we need to be more diligent about what gets
committed to master/master-1.2.x vs what gets committed to feature
branches.  In our current model, even broken features will catch the
train because everything is committed to master-1.2.x by default.

John Reese

This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
mantisbt-dev mailing list