Re: GCC 5.1.0 in mxe-octave

[Carnë Draug]

On 6 May 2015 at 21:05, John W. Eaton <address@hidden> wrote:
> [...]
> More generally, how should we manage Octave releases and mxe-octave
> development?  I'd guess that whatever Octave 4.0.x releases that we make
> should be done with the same set of tools.  Also possibly with the same set
> of packages, with only bug fixes applied, same as we do for the Octave
> releases themselves.  But I don't know that we have a good way of handling
> that as package development proceeds separately from Octave development.
>

I'd say to use the last patch release of the same minor release of the
package that was present in Octave 4.0.0.  So to be more clear, if Octave
4.0.0 is released with control 2.8.1, then Octave 4.0.1 could be released
with the latest control 2.8.X at the time of release, but not anything
above that.

This would require package developers to use the same rationale as core
to decide if a patch would go into "stable" or "default", which at the
moment does not really happen so it would require core to pay close attention
to the diff between packages.  It would also require package developers
to maintain a old branch and backports patches into it if they want the
next release of Octave to include the fix which is also not ideal.

In an ideal situation, Octave would install pre-built forge packages,
package developers would be able to upload such packages somewhere, and
Octave core would not have to be released with packages at all.  This would
also prevent package developers from rushing out a release in order to get
it into the next octave release (kind of what sometimes happens with upstream
packages before a freeze of a Linux distro). I don't have a solution for
any of this though.

Carnë