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:59:12 -0800

On 01/30/2015 09:46 AM, John W. Eaton wrote:
> On 01/30/2015 12:15 PM, Rik wrote:
>
>> 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 wasn't aware of that.  I had hoped that classdef wouldn't cause trouble
> if it wasn't being used.
>
>> 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.
>
> I don't expect that classdef will be 100% functional for 4.0.  We could
> possibly have a warning about that.
>
>> 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.
>
> 222 bug fixes seems like a lot to graft and review.  I expect many
> conflicts in that process.  Plus all the changes related to graphics and
> even the GUI that went on default but were not strictly bug fixes.

Yes, it's a bit of a pickle either way.  You seemed to have much better
luck than I did quickly generating the backout changesets so maybe that is
the way to go.  I didn't see the file NEWS in the diff, so maybe that has
to be manually modified to reflect what has been kept and what has not.  I
also like to put the version number when a function was deprecated in the
m-file in scripts/deprecated/*.m.  Those should be changed to 4.0 instead
of 4.2.

--Rik



reply via email to

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