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: Rik
Subject: Re: Keeping the gui-release branch open considered harmful
Date: Fri, 30 Jan 2015 09:15:27 -0800

On 01/30/2015 08:13 AM, address@hidden wrote:
Subject:
Re: Keeping the gui-release branch open considered harmful
From:
Michael Godfrey <address@hidden>
Date:
01/29/2015 06:21 PM
To:
"John W. Eaton" <address@hidden>, address@hidden
List-Post:
<mailto:address@hidden>
Content-Transfer-Encoding:
7bit
Precedence:
list
MIME-Version:
1.0
References:
<address@hidden> <address@hidden> <address@hidden> <address@hidden> <address@hidden>
In-Reply-To:
<address@hidden>
Message-ID:
<address@hidden>
Content-Type:
text/plain; charset=utf-8; format=flowed
Message:
2


On 01/29/2015 05:50 PM, John W. Eaton wrote:
An offer I'll probably regret:

I'd even be willing to spend a little bit of time restoring the deprecated functions that have been removed in default (at least the ones for which that's a relatively trivial job).

And finally, an optimistic statement that will probably turn out to be completely false:

I don't know for sure since I haven't tried it, but I think that restoring the deprecated functions that were removed on the default branch should just be a matter of backing out some changesets that were made soon after the gui-release branch was created.

jwe

As long as someone else is willing to do tackle this :)

There was a mix-up around the creation of the gui-release branch and it took me probably 4-8 hours to get it straightened out which I don't want to do again.  On the other hand, I had an imperfect understanding of Mercurial at the time.

Another downside is that the current development branch has the accumulated non-GUI bug fixes for Octave, but it also brings with it classdef which has not been significantly tested.  For example,

strfind ("strfind.cc", "cc")
error: invalid meta.package indexing

I think doing any significant testing of classdef, perhaps asking people to try classdef code they have written on the development branch, would delay a release too far into the future.

A simpler solution might be to backport important bug fixes using either hg graft or hg transplant.  There are about 222 of these to review.

hg log -r a1e4282f5254: -b dev -k 'bug #' | grep 'changeset:' | wc -l

The focus of 4.0 is a GUI with Windows support so bugs related to display, Windows incompatibilities, and plotting output would be the ones I would backport.

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.

--Rik





reply via email to

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