Re: What's appropriate for the default branch?

[Rik]

On 11/28/2013 10:13 AM, John W. Eaton wrote:
> 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?
>
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.  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.  Those are my thoughts, but either way
will be fine for me.

--Rik