What's appropriate for the default branch? (was: Re: Default branch merged to stable)

[John W. Eaton]

On 11/26/2013 01:20 AM, Rik wrote:

> If you have changesets for the 3.8 release they should now
> be applied to the stable branch.  The default branch is now for development
> on the 4.0 release.

What's appropriate for the default branch now?

If our focus for 4.0 is a solid GUI, then I think we should focus on
that alone and leave other changes until later.  But that means that
we don't really have a good place for people to push changes for new
features that are not focused on the GUI or classdef.

I also don't think that we should be doing all the work for 4.0 on the
stable branch.  We may have to break binary compatibility when making
some of the 4.0 changes and it may take more than a few months for 4.0
to be ready.  But we should try to ensure that we are able to release
3.8.N at any time without breaking binary compatibility with previous
3.8 releases.

Would it make sense to create an intermediate branch that is intended
for the work on the 4.0 release?  Then we could leave default open for
any other kinds of possibly risky changes.  If we go this route, I
would merge classdef to default.

Then we would have:

  stable:  3.8.x series

  gui:     Future 4.0.x series with stable GUI.  Most work focuses on
           this branch until 4.0 is released.

  default: The usual (almost) anything goes branch.  Merge classdef
           here and close the classdef branch.  The big new feature
           for a future 4.x release (or maybe 5.0) would be classdef
           support.

But I would also like to propose that we try to have a better plan for
default than we have had in the past and avoid a truly "anything goes"
approach because that's the kind of thing that results in new stable
releases not happening for two or more years.

Comments?

jwe