Release Ideas

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

John Swensen-3

On Jan 28, 2015, at 3:48 PM, Ben Abbott <[hidden email]> wrote:

On Jan 28, 2015, at 3:24 PM, John W. Eaton <[hidden email]> wrote:

On 01/28/2015 02:50 PM, John Swensen wrote:

I know it is a cop-out, but is it really too hard to ask people to go to a terminal and type:

Yeah, I suspect it is.

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

and then type:
brew tap homebrew/science
brew install gfortran
brew update && brew upgrade
brew install gcc
brew install octave

I know this is a bit harder, but for a "unsupported" platform it is still quite easy. The only issue is that for the homebrew recipe that the gui is not the default and you have to run "octave --force-gui"

How long does this process take for someone who is installing everything for the first time?

Even if you scripted this and put a pretty GUI "one-click" installer around it, I suspect most users would find it annoying that it takes possibly hours to install while the system is quite busy.

Also, if it is this simple to build Octave from homebrew, why do we see so many people complaining about how hard it is to build Octave for OS X?

I think the biggest hurdle for Mac OSX is that Yosemite's clang has broken a some things. Both Fink and Macports are now able to build 3.8.2 on Yosemite, but those solutions do not work for me using the default branch. My impression (and not a reliable one) is that I'll need clang 6 before a build can be successful..

Finally, if it is this simple, then why hasn't anyone turned the resulting binaries into a simple installer?  Is that part difficult?

That would be easy, but Octave would end up installed in the directory structure reserved for Homebew, Macports, or Fink.

Ben

I guess I haven't tried building on Yosemite (I always wait a while to install the latest and greatest from Apple). Homebrew has always "just worked" for me on Mountain Lion and Mavericks.

As to the amount of time it takes to install via homebrew, I uninstalled my entire Homebrew directory and deleted the download cache and reinstalled. It took about 24 minutes to install everything. I put the install log on pastebin at http://pastebin.com/guzfNNLS

When reading the install log, note that every download that is of the form package_name.bottle.tar.gz is a binary installation that doesn't have to be compiled. Very few of the Octave dependencies installed through Homebrew actually have to be compiled. I actually have a pretty slow broadband connection (3Mbps) so I suspect that a ton of those 24 minutes was just downloading the packages.

So, still not super simple, but simple enough that <insert arbitrary high percentage here> of people could do it (pre-Yosemite) with some handholding.

John S.
Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

John W. Eaton
Administrator
In reply to this post by John W. Eaton
On 01/28/2015 12:09 PM, John W. Eaton wrote:
> On 01/28/2015 08:31 AM, JohnD wrote:
>
>> Not sure if it falls under Qt plotting but including printing using
>> the Qt
>> widgets rather than having to switch toolkits would be nice.
>> https://savannah.gnu.org/bugs/index.php?42537
>
> Yes, this should definitely be fixed if using the qt widgets for
> plotting is the default.

I posted a patch to the bug tracker.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

c.-2
In reply to this post by bpabbott

On 28 Jan 2015, at 22:00, Ben Abbott <[hidden email]> wrote:

> I've done that myself. I even modified it to install as a relocatable bundle ... but it wasn't an easy task. If we don't make it relocatable, is there a way to enure there isn't a conflict?

The 3.8.0/3.8.2 .dmg/.mpkg distribution on Source Forge installs a full Macports tree in /usr/local/octave/<version number>
and a .app launcher in /Applications. The .app launcher can be moved anywhere but the actual binaries and libraries must
be in that path.

I can produce a similar distrbution for 4.0 with Mavericks and, according to feedback I have received for the 3.8.2, release
it will probably work on Yosemite as well.

The problem is that it almost certainly will not be able to install packages as the developer tools on Mavericks and Yosemite
are different versions.

I did not update to Yosemite yet and I will not be able to do so for a while as I found some code I use for my research work
will not build on Yosemite so I need to stick with Mavericks.

> Ben
c.
Reply | Threaded
Open this post in threaded view
|

RE: Release Ideas

John Donoghue-3
In reply to this post by John W. Eaton


> -----Original Message-----
> From: John W. Eaton [mailto:[hidden email]]
> Sent: Thursday, January 29, 2015 9:32 AM
> To: JohnD; [hidden email]
> Subject: Re: Release Ideas
>
> On 01/28/2015 12:09 PM, John W. Eaton wrote:
> > On 01/28/2015 08:31 AM, JohnD wrote:
> >
> >> Not sure if it falls under Qt plotting but including printing using
> >> the Qt widgets rather than having to switch toolkits would be nice.
> >> https://savannah.gnu.org/bugs/index.php?42537
> >
> > Yes, this should definitely be fixed if using the qt widgets for
> > plotting is the default.
>
> I posted a patch to the bug tracker.
>
> jwe
>

Works in fedora for me - compiling a new mxe-octave now.


Reply | Threaded
Open this post in threaded view
|

RE: Release Ideas

John Donoghue-3
In reply to this post by John W. Eaton


> -----Original Message-----
> From: John W. Eaton [mailto:[hidden email]]
> Sent: Thursday, January 29, 2015 9:32 AM
> To: JohnD; [hidden email]
> Subject: Re: Release Ideas
>
> On 01/28/2015 12:09 PM, John W. Eaton wrote:
> > On 01/28/2015 08:31 AM, JohnD wrote:
> >
> >> Not sure if it falls under Qt plotting but including printing using
> >> the Qt widgets rather than having to switch toolkits would be nice.
> >> https://savannah.gnu.org/bugs/index.php?42537
> >
> > Yes, this should definitely be fixed if using the qt widgets for
> > plotting is the default.
>
> I posted a patch to the bug tracker.
>
> jwe
>

Works in windows gui, although there is an issue:
Running:
plot([1:10)
print t.png

The displayed plot line is NOT solid from 1,1 to 10,10
1,1-6,6 is good, there is a gap with a faint line between 6,6-9,9 and then
9,9-10,10 is solid again.
It also occurs using the fltk toolkit, and also saving as .eps etc.

Gnuplot doesn't do it.

Running a mxe-octave 3.8.2 version with fltk works fine.






Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

John Swensen-3
In reply to this post by c.-2

On Jan 29, 2015, at 10:40 AM, c. <[hidden email]> wrote:


On 28 Jan 2015, at 22:00, Ben Abbott <[hidden email]> wrote:

I've done that myself. I even modified it to install as a relocatable bundle ... but it wasn't an easy task. If we don't make it relocatable, is there a way to enure there isn't a conflict?

The 3.8.0/3.8.2 .dmg/.mpkg distribution on Source Forge installs a full Macports tree in /usr/local/octave/<version number>
and a .app launcher in /Applications. The .app launcher can be moved anywhere but the actual binaries and libraries must
be in that path.

I can produce a similar distrbution for 4.0 with Mavericks and, according to feedback I have received for the 3.8.2, release
it will probably work on Yosemite as well.

The problem is that it almost certainly will not be able to install packages as the developer tools on Mavericks and Yosemite
are different versions.

I did not update to Yosemite yet and I will not be able to do so for a while as I found some code I use for my research work
will not build on Yosemite so I need to stick with Mavericks.

Ben
c.

A while ago, I used the dylibbundler tool (https://github.com/auriamg/macdylibbundler) to generate a .app from something I compiled elsewhere. Granted, the program I was putting in the .app was a single binary with no supporting files and only a few dependencies. 

Is there a reason we couldn't do this with Octave?I realize it could result in an enormous .app file because we would be putting all the relocated libraries inside of the .app file, but I think it would work. Also, as long as is was built for Mountain Lion or Mavericks, is *should* work on Yosemite too. A little searching found a pretty complicated script that does the entire relocating and .app creation process for FontForge (https://github.com/fontforge/fontforge/blob/master/travis-scripts/create-osx-app-bundle-homebrew.sh#L118).

Carlo Falco and Ben Abbot,
Do you see any major hangups with this approach? I have been meaning to get back to helping Octave out more actively and maybe this is something I could take on.

John S.
Reply | Threaded
Open this post in threaded view
|

Keeping the gui-release branch open considered harmful (was: Re: Release Ideas)

John W. Eaton
Administrator
In reply to this post by Michael Godfrey
On 01/27/2015 10:48 PM, Michael Godfrey wrote:

>
> On 01/27/2015 07:35 PM, John W. Eaton wrote:
>> On 01/27/2015 06:40 PM, Michael Godfrey wrote:
>>
>>> Unless there is something blocking default, why not just make one
>>> release (default already has all the
>>> GUI code).
>>
>> We deprecated some things in 3.8 that have already been removed from
>> default but not gui-release.  Normally we have one release that still
>> contains the deprecated functions but warns if they are used. Skipping
>> the gui-release release and going straight to default would break this
>> promise that we normally make.  Not a huge thing, I suppose, but
>> something we should consider if we decide to just release default.
>>
>> jwe
>>
> That is a concern. But, it might make sense to amend the deprecated
> functions rule to 1 release or some
> substantial length of time since the deprecated announcement.
> A compromise might be to make the GUI  branch at the point it is closed
> available for download for anyone who depends on the deprecated
> functions, but go ahead with the
> "official" release of the default. This would make the benefits of the
> default available and close down
> the 2 versions under development problem.
>
> I am confident that practically all users will be happier with the
> default branch.

Executive summary:

We should just merge gui-release to default one last time and close
gui-release as the gui-release branch has become more of a hassle than
it is worth.

Rant:

While working on making printing work for Qt widgets, I wanted to do a
little code refactoring.  I wasn't paying close attention and was
working on default even though I should have been on gui-release because
these changes need to be done for the first release with the GUI.  When
I noticed my mistake, I thought I would just move my changes over to
gui-release, then merge them back to stable.  But my changes did not
apply cleanly to gui-release because there were significant differences
between gui-release and default for the functions I was working on.  So,
I could continue, clean up the patches so they work with gui-release,
merge them to default, fix up the conflicts (AGAIN!) and then go on
hating my day and the fact that I ever thought up this idea of a third
branch of development.

Even if I had started working on gui-release, I would have faced the
same problem of conflicts when merging from gui-release to default
because I was making changes where the code has diverged.

This is not the first time I've had trouble like this, and I'm sure it
won't be the last if we continue to keep both gui-release and default open.

Yes, we still have the same problems with stable and gui-release (or
default), but we aren't making many changes to stable, so these
conflicts don't come up as often.

So, instead of fighting this battle again and again, we could just save
ourselves a lot of confusion and wasted time and drop this idea of a
release from gui-release.

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


Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

bpabbott
Administrator
In reply to this post by John Swensen-3
On Jan 29, 2015, at 3:57 PM, John Swensen <[hidden email]> wrote:

On Jan 29, 2015, at 10:40 AM, c. <[hidden email]> wrote:

On 28 Jan 2015, at 22:00, Ben Abbott <[hidden email]> wrote:

I've done that myself. I even modified it to install as a relocatable bundle ... but it wasn't an easy task. If we don't make it relocatable, is there a way to enure there isn't a conflict?

The 3.8.0/3.8.2 .dmg/.mpkg distribution on Source Forge installs a full Macports tree in /usr/local/octave/<version number>
and a .app launcher in /Applications. The .app launcher can be moved anywhere but the actual binaries and libraries must
be in that path.

I can produce a similar distrbution for 4.0 with Mavericks and, according to feedback I have received for the 3.8.2, release
it will probably work on Yosemite as well.

The problem is that it almost certainly will not be able to install packages as the developer tools on Mavericks and Yosemite
are different versions.

I did not update to Yosemite yet and I will not be able to do so for a while as I found some code I use for my research work
will not build on Yosemite so I need to stick with Mavericks.

Ben
c.

A while ago, I used the dylibbundler tool (https://github.com/auriamg/macdylibbundler) to generate a .app from something I compiled elsewhere. Granted, the program I was putting in the .app was a single binary with no supporting files and only a few dependencies. 

Is there a reason we couldn't do this with Octave?I realize it could result in an enormous .app file because we would be putting all the relocated libraries inside of the .app file, but I think it would work. Also, as long as is was built for Mountain Lion or Mavericks, is *should* work on Yosemite too. A little searching found a pretty complicated script that does the entire relocating and .app creation process for FontForge (https://github.com/fontforge/fontforge/blob/master/travis-scripts/create-osx-app-bundle-homebrew.sh#L118).

Carlo Falco and Ben Abbot,
Do you see any major hangups with this approach? I have been meaning to get back to helping Octave out more actively and maybe this is something I could take on.

John S.

No. I think it should work. Setting up the environment so that everything works will need some effort (i.e. mkoctfile and an initialization/launch script). I had made some progress on this approach a few years back.


I have little time for Octave now, and would be thrilled so see someone take this on. If you’re up for that I can answer questions.

Ben


Reply | Threaded
Open this post in threaded view
|

Re: Keeping the gui-release branch open considered harmful

Michael Godfrey
In reply to this post by John W. Eaton

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
John,

I think that this makes clear that maintaining GUI and default is
causing a lot more problems
than it could possibly be worth. It is hard to imagine that doing a
final merge and work form there
would be harder than dealing with all the divergent problems of 2 branches.

Michael


Reply | Threaded
Open this post in threaded view
|

Re: Keeping the gui-release branch open considered harmful

John W. Eaton
Administrator
On 01/29/2015 09:21 PM, Michael Godfrey wrote:

> I think that this makes clear that maintaining GUI and default is
> causing a lot more problems
> than it could possibly be worth. It is hard to imagine that doing a
> final merge and work form there
> would be harder than dealing with all the divergent problems of 2 branches.

Any other comments on this, or should I just close the branch?

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Keeping the gui-release branch open considered harmful

Carnë Draug
On 30 January 2015 at 15:27, John W. Eaton <[hidden email]> wrote:

> On 01/29/2015 09:21 PM, Michael Godfrey wrote:
>
>> I think that this makes clear that maintaining GUI and default is
>> causing a lot more problems
>> than it could possibly be worth. It is hard to imagine that doing a
>> final merge and work form there
>> would be harder than dealing with all the divergent problems of 2
>> branches.
>
> Any other comments on this, or should I just close the branch?

While we use different branches to mean releases, branches can also
just mean a large piece of development that we want to happen separate
from the rest of development.

If we forget that the gui-release branch was meant to be a release on
its own, merging it back on default now that it is ready makes all the
sense.  Maybe we should have seen it like that from the very start, in
which case we would not had removed the deprecated stuff, but oh well.
Hopefully it will be simple to get the removed stuff back.

So yeah, I think this is a good idea.  Simple question, will the next
release be 4.2 or 4.0?

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: Keeping the gui-release branch open considered harmful

John W. Eaton
Administrator
On 01/30/2015 10:47 AM, Carnë Draug wrote:

> So yeah, I think this is a good idea.  Simple question, will the next
> release be 4.2 or 4.0?

I would make it 4.0.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Keeping the gui-release branch open considered harmful

Michael Godfrey

On 01/30/2015 11:03 AM, John W. Eaton wrote:
> I would make it 4.0.
>
> jwe
>
Great.  It appears that everyone agrees to the merge, or at least has
not disagreed,
so now would be a good time to do it! 4.0 seems right to me.

Michael


Reply | Threaded
Open this post in threaded view
|

Re: Keeping the gui-release branch open considered harmful

Daniel Sebald
In reply to this post by John W. Eaton
On 01/30/2015 09:27 AM, John W. Eaton wrote:

> On 01/29/2015 09:21 PM, Michael Godfrey wrote:
>
>> I think that this makes clear that maintaining GUI and default is
>> causing a lot more problems
>> than it could possibly be worth. It is hard to imagine that doing a
>> final merge and work form there
>> would be harder than dealing with all the divergent problems of 2
>> branches.
>
> Any other comments on this, or should I just close the branch?

I haven't been following the branch development that closely as of late.
  I'd say that if there are a lot of conflicts occurring with a merge
then something probably is no longer organized in a meaningful way.
Where are the conflicts occurring?  Are there elements of the GUI in
both the GUI branch and the default branch?  There probably shouldn't
be.  How about changes/fixes in the core code?  Those probably shouldn't
be in the GUI branch, but only in the default branch.  A lot of the bug
fixes in the default branch have little bearing on GUI development
(e.g., one can do GUI development without a fix in the parser behavior
no matter how critical that fix is to the overall project).

To me, branching is either for creating a whole new project (e.g.,
SeaMonkey from FireFox) or for something experimental that will last for
a few weeks or months until it is stable and then be moved in or
truncated if the concept doesn't work out as hoped.  (Whatever time
frame it makes sense to maintain the separation.)  Moving bits and
pieces across branches every once in a while is probably not good
because in some sense it is a bit like trying to maintain a branch
against an older version of itself.

In hindsight, a better model may have been to keep the GUI isolated to
one branch and when it comes time to release a beta version of Octave
with the GUI then do a merge of the two branches as a temporary offshoot
of the GUI (i.e., a GUI beta version release would be a hybrid "stub" or
"bud").  The same idea would have worked for Qt graphics.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Keeping the gui-release branch open considered harmful

John W. Eaton
Administrator
In reply to this post by Carnë Draug
On 01/30/2015 10:47 AM, Carnë Draug wrote:

> Hopefully it will be simple to get the removed stuff back.

I propose that we only bring back the functions that were removed from
the deprecated directory.  We would still make changes to the configure
script, remove the static keyword, remove Octave_map.  My proposed
changeset is attached.

jwe


undeprecate-changeset.txt (39K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keeping the gui-release branch open considered harmful

Rik-4
In reply to this post by Michael Godfrey
On 01/30/2015 08:13 AM, [hidden email] wrote:
Subject:
Re: Keeping the gui-release branch open considered harmful
From:
Michael Godfrey [hidden email]
Date:
01/29/2015 06:21 PM
To:
"John W. Eaton" [hidden email], [hidden email]
List-Post:
[hidden email]
Content-Transfer-Encoding:
7bit
Precedence:
list
MIME-Version:
1.0
References:
[hidden email] [hidden email] [hidden email] [hidden email] [hidden email]
In-Reply-To:
[hidden email]
Message-ID:
[hidden email]
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 | Threaded
Open this post in threaded view
|

Re: Keeping the gui-release branch open considered harmful

John W. Eaton
Administrator
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.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Keeping the gui-release branch open considered harmful

Daniel Sebald
In reply to this post by Rik-4
On 01/30/2015 11:15 AM, Rik wrote:
> On 01/30/2015 08:13 AM, [hidden email] wrote:
>> Subject:
>> Re: Keeping the gui-release branch open considered harmful

[snip]

> 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.

What is the history of classdef?  It looks to me that it was a separate
branch and then merged and truncated in December 2013.  After that,
there is only sporadic activity related to classdef and it is in default
branch.

It's been around a while.  Is it that GUI code the first major use of
classdef?

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Keeping the gui-release branch open considered harmful

Rik-4
In reply to this post by John W. Eaton
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 | Threaded
Open this post in threaded view
|

Re: Keeping the gui-release branch open considered harmful

Daniel Sebald
In reply to this post by John W. Eaton
On 01/30/2015 11:46 AM, John W. Eaton wrote:
> On 01/30/2015 12:15 PM, Rik wrote:
>

[snip]

>> 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.

I've no idea, but is there an easy way of disabling the use of classdef
in the GUI?  If so, the merge of the GUI could go forward, then disable
classdef usage in a changeset, create the version, then restore the
classdef usage.

Dan

123