Re: 3.8 -> 4.0 transition plans

[Mike Miller]

On Mon, 2 Dec 2013 18:55:46 -0500, John W. Eaton wrote:
> On 12/02/2013 05:02 PM, Jordi Gutiérrez Hermoso wrote:
>> I think the following proposal makes sense:
>>
>>     1) Work for the next few days on the stable branch until a release
>>        is ready, in whatever state it is in within the next few days.
>>        The outstanding big bugs are in the GUI, and we've agreed that
>>        we'll just release with those bugs and the warnings that jwe has
>>        put in.
>>
>>     2) Create a new gui-release branch based off current default
>>
>>     3) Merge classdef into default. Close classdef branch.
>>
>>     4) New experimental features and development go into the default
>>        branch. This will either be a 4.2 or 5.x release.
>>
>>     5) Merging order goes like this: stable -> gui-release -> default
>>
>>     6) After the 3.8 release, we work hard on the gui-release branch
>>        and release 4.0 from gui-release. Final merge of gui-release
>>        into default and close gui-release. Hopefully we can do this
>>        within a few months, say, no more than 4.
>>
>>     7) Try to focus all efforts on gui-release to the extent that a
>>        3.8.1 release won't even be necessary, but as usual, critical
>>        bugs in the 3.8 release get patched on stable and forward-merged
>>        into release-gui and default, just in case we really do need to
>>        do 3.8.1
>>
>> So, basically, replace the classdef branch by putting it into default
>> and adding an intermediate gui-release branch between stable and
>> default.
>>
>> Sounds good?
> 
> Yes.  That's more detailed that what I proposed earlier, but I think
> it's the same general idea.

This plan looks good to me too. I had planned on replying to the earlier
plan in this thread that it was confusing and I would not know which
branch certain fixes should go on. This clears things up quite a lot.

The key points that made this more practical to me are the time frames
and merge plans. This basically allows the GUI work to stay in "release
mode" for a not-too-far-in-the-future 4.0 release while development on
default works as before for the next release beyond that.

There is still ambiguity about where non-GUI bug fixes should go. In the
last release cycle, mostly documentation and regression bug fixes went
on the stable branch for the next point release. In this plan, some
measure of criticality will determine whether a non-GUI bug fix should
go on stable, gui-release, or default.

If we stick to the plan of having a 4.0 improved GUI release very soon,
less than 6 months, then it's ok to put non-regression bug fixes on the
default branch as before, and say that the fix will be released in 4.2.
If the schedule slips, then we end up having a 4.0 release with a new
GUI but a whole backlog of fixed bugs that won't be released for another
year or so. These are my main concerns about this plan, any thoughts?

-- 
mike