octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Keeping the gui-release branch open considered harmful


From: Mike Miller
Subject: Re: Keeping the gui-release branch open considered harmful
Date: Fri, 30 Jan 2015 14:51:22 -0500
User-agent: Mutt/1.5.23 (2014-03-12)

On Fri, Jan 30, 2015 at 09:15:27 -0800, Rik wrote:
> But the original comment still stands.  If someone is willing to merge the
> two branches and everyone feels that classdef and the new audio system are
> ready for release then I won't stand in the way.

I think I'm with Rik here. I was and am in favor of keeping the branches
and release plans we had made last year, but I'm not aware of the size
of the accumulated delta between the two branches and the difficulty
that might bring with fixing things on gui-release and having to
significantly rework them to merge them on the default branch.

I still think a more stable 4.0 GUI release with much improved Windows
support would be better. Even if it doesn't bring any of a number of
fixes that have been made on default. How many more large changes would
need to be made on gui-release before a 4.0 release that would need to
be refactored to be merged onto default?

I don't deal with merging the mercurial branches at all, so I have no
concept of how much work it's been to maintain this model.

So all that said, if it is too large of a burden to make significantly
different fixes on the two branches, I'm ok with closing gui-release and
making default be the 4.0 release.

I made a similar comment to jwe on irc the other day about classdef. I'm
wary about making it part of the next release, since it affects the
parser, but as long as it doesn't introduce any problematic regressions
it should be fine to have it as a new feature for users to experiment
with and test for us.

Since we're talking release soon-ish either way, I've started looking
through the bug tracker to identify crashes and bugs that look like they
might be blockers.

-- 
mike



reply via email to

[Prev in Thread] Current Thread [Next in Thread]