Re: What's appropriate for the default branch?

[John W. Eaton]

On 11/29/2013 07:11 PM, Rik wrote:

> I agree that the stable branch should remain slow-to-change and no
> significant development work (GUI or otherwise) should take place there.
> As for the the other, I like the simplicity of ping/ponging between a
> stable and a development branch and would be just as happy without a third
> GUI branch.  In my experience the default branch has not been wildly
> experimental.  Except for a few days spread over the years, one could
> always just do an 'hg pull; bootstrap; config; make' cycle and have it
> work.  I could see isolating the GUI work if we thought that other changes
> were going to de-stabilize the source tree to such a degree that it might
> not be releasable in 6 months, but that hasn't been the past history of the
> archive.

My impression is that we are rarely ready for release.  When we
announce that we are about to release, everyone suddenly shows up with
a bunch of "must fix" bug reports and it takes us months to actually
make a release.

I'm not sure what the solution to this problem is.  More frequent
regular releases regardless of whether some big new feature like the
GUI or classdef is really finished?  Maintaining a
"we-could-release-from-this-at-any-time" branch that is not open for
changes unless tehy are truly finished and well tested?

I'm not thrilled about having a lot of branches, but in this
particular case I think it makes sense to have the separate branch for
the 4.0 with the GUI for real release.  I would just do that work on
stable but I'm thinking that it will take long enough to get 4.0 ready
that we may need to make another 3.8.x release.

> Now maybe the changes on the classdef branch do represent such a
> change, but if they are more than 6 months from finalization then maybe
> they should just continue to live on their own separate named branch rather
> than hijacking the default branch.

If we do that, then I think classdef doesn't get much testing.

jwe