Time for a 4.0.1 bug fix release?

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Time for a 4.0.1 bug fix release?

Rik-4
10/19/15

All,

Version 4.0.0 was released in May, and it is now nearly November, i.e., 6
months later.

Using hg log -b stable -r release-4-0-0:: > stable.log

There are just 74 changesets, but quite a few important fixes for
segfaults, mis-calculated results, and regressions, as well as just
documentation.  It would be nice to have some sort of fix for the crashes
that lots of people seem to be having with OpenGL graphics, but I don't
think we have an answer there so it isn't worth delaying.

My vote is for a 4.0.1 bug fix release in November.

Cheers,
Rik


Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

Michael Godfrey


On 10/19/2015 04:19 PM, Rik wrote:
> My vote is for a 4.0.1 bug fix release in November.
My vote is the same!!


Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

jbect
Le 19/10/2015 17:44, Michael Godfrey a écrit :
> On 10/19/2015 04:19 PM, Rik wrote:
>> My vote is for a 4.0.1 bug fix release in November.
> My vote is the same!!
Yes, please, release!


Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

edmund ronald
Please, if you do a bugfix, publish it to the Octave repository. 

Edmund

On Mon, Oct 19, 2015 at 5:54 PM, Julien Bect <[hidden email]> wrote:
Le 19/10/2015 17:44, Michael Godfrey a écrit :
On 10/19/2015 04:19 PM, Rik wrote:
My vote is for a 4.0.1 bug fix release in November.
My vote is the same!!
Yes, please, release!



Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

Carnë Draug
In reply to this post by Rik-4
On 19 October 2015 at 16:19, Rik <[hidden email]> wrote:

> 10/19/15
>
> All,
>
> Version 4.0.0 was released in May, and it is now nearly November, i.e., 6
> months later.
>
> Using hg log -b stable -r release-4-0-0:: > stable.log
>
> There are just 74 changesets, but quite a few important fixes for
> segfaults, mis-calculated results, and regressions, as well as just
> documentation.  It would be nice to have some sort of fix for the crashes
> that lots of people seem to be having with OpenGL graphics, but I don't
> think we have an answer there so it isn't worth delaying.
>
> My vote is for a 4.0.1 bug fix release in November.

What should be done about the packages that go with the MXE releases?
Was there any consensus about what versions to use for that?  Should we:

1) use the exact same versions released with 4.0.0 (unfair, why don't the
packages get a chance for fix their issues)

2) the package last patch release for the version released with 4.0.0 (but
most OF packages don't follow core in only accepting regression fixes in
those patch releases)

3) the last release of each package (not great if we want to extend the
backwards compatible promise to the packages in the MXE distribution)

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

Rik-4
On 10/19/2015 09:09 AM, Carnë Draug wrote:

> On 19 October 2015 at 16:19, Rik <[hidden email]> wrote:
>> 10/19/15
>>
>> All,
>>
>> Version 4.0.0 was released in May, and it is now nearly November, i.e., 6
>> months later.
>>
>> Using hg log -b stable -r release-4-0-0:: > stable.log
>>
>> There are just 74 changesets, but quite a few important fixes for
>> segfaults, mis-calculated results, and regressions, as well as just
>> documentation.  It would be nice to have some sort of fix for the crashes
>> that lots of people seem to be having with OpenGL graphics, but I don't
>> think we have an answer there so it isn't worth delaying.
>>
>> My vote is for a 4.0.1 bug fix release in November.
> What should be done about the packages that go with the MXE releases?
> Was there any consensus about what versions to use for that?  Should we:
>
> 1) use the exact same versions released with 4.0.0 (unfair, why don't the
> packages get a chance for fix their issues)
>
> 2) the package last patch release for the version released with 4.0.0 (but
> most OF packages don't follow core in only accepting regression fixes in
> those patch releases)
>
> 3) the last release of each package (not great if we want to extend the
> backwards compatible promise to the packages in the MXE distribution)
>
> Carnë
I would use either option 1 (unfair, but people who want the latest package
can always go get it themselves from Octave-Forge.  We are just trying to
be nice by including a selection of the most common packages in the same
installer as core Octave) or option 2 (Octave-Forge has its own rules and
we don't extend the core guarantee about compatibility on to the packages).

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

John W. Eaton
Administrator
In reply to this post by Carnë Draug
On 10/19/2015 12:09 PM, Carnë Draug wrote:
> On 19 October 2015 at 16:19, Rik <[hidden email]> wrote:

>> My vote is for a 4.0.1 bug fix release in November.
>
> What should be done about the packages that go with the MXE releases?
> Was there any consensus about what versions to use for that?  Should we:

I agree that we should make a bug fixing release soon.

For the Windows binary I'll use whatever packages you decide are best.
I have no strong opinion about that, except that it's probably best to
err on the side of stability, whatever that means.  How to decide that
might vary from package to package.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

Avinoam
In reply to this post by Rik-4

Hi,

 

Can someone build the stable version and put  it as a release candidate in [1]?

 

Thanks,

 

Avinoam

 

[1]  [https://ftp.gnu.org/gnu/octave]

 

Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

John W. Eaton
Administrator
On 10/25/2015 03:49 PM, Avinoam Kalma wrote:

> Hi,
>
> Can someone build the stable version and put  it as a release candidate
> in [1]?
>
> Thanks,
>
> Avinoam
>
> [1]  [https://ftp.gnu.org/gnu/octave]

Release candidates will be distributed from alpha.gnu.org.

I'll try to find some time to work on that this week.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

Oliver Heimlich
On 26.10.2015 04:15, John W. Eaton wrote:
> On 10/25/2015 03:49 PM, Avinoam Kalma wrote:
>> Hi,
>>
>> Can someone build the stable version and put  it as a release candidate
>> in [1]?

I am particularly interested in getting regression #44334 fixed in that
bug fix release. Could somebody please apply the patch which is waiting
at Savannah?

>>
>> Thanks,
>>
>> Avinoam
>>
>> [1]  [https://ftp.gnu.org/gnu/octave]
>
> Release candidates will be distributed from alpha.gnu.org.
>
> I'll try to find some time to work on that this week.
>
> jwe
>

Sounds great!

Oliver

Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

Oliver Heimlich
In reply to this post by Rik-4
On 19.10.2015 18:24, rik wrote:

> On 10/19/2015 09:09 AM, Carnë Draug wrote:
>> On 19 October 2015 at 16:19, Rik <[hidden email]> wrote:
>>> 10/19/15
>>>
>>> All,
>>>
>>> Version 4.0.0 was released in May, and it is now nearly November, i.e., 6
>>> months later.
>>>
>>> Using hg log -b stable -r release-4-0-0:: > stable.log
>>>
>>> There are just 74 changesets, but quite a few important fixes for
>>> segfaults, mis-calculated results, and regressions, as well as just
>>> documentation.  It would be nice to have some sort of fix for the crashes
>>> that lots of people seem to be having with OpenGL graphics, but I don't
>>> think we have an answer there so it isn't worth delaying.
>>>
>>> My vote is for a 4.0.1 bug fix release in November.
>> What should be done about the packages that go with the MXE releases?
>> Was there any consensus about what versions to use for that?  Should we:
>>
>> 1) use the exact same versions released with 4.0.0 (unfair, why don't the
>> packages get a chance for fix their issues)
>>
>> 2) the package last patch release for the version released with 4.0.0 (but
>> most OF packages don't follow core in only accepting regression fixes in
>> those patch releases)
>>
>> 3) the last release of each package (not great if we want to extend the
>> backwards compatible promise to the packages in the MXE distribution)
>>
>> Carnë
> I would use either option 1 (unfair, but people who want the latest package
> can always go get it themselves from Octave-Forge.  We are just trying to
> be nice by including a selection of the most common packages in the same
> installer as core Octave) or option 2 (Octave-Forge has its own rules and
> we don't extend the core guarantee about compatibility on to the packages).
>
> --Rik

I find this question very difficult, because there are good reasons for
each of the options.

However, given that the bundled packages are mainly for simplification
of package installation for Windows users, and that there is no
distinction between different kind of package releases (pkg install
-forge will always install the latest release; there is no common way
how bugfix releases are handled at Octave Forge) I suggest to simply use
option 3. Also this will place the responsibility for the package
releases on the package maintainers.

Oliver

Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

PhilipNienhuis
In reply to this post by Carnë Draug
Carnë Draug wrote
On 19 October 2015 at 16:19, Rik <[hidden email]> wrote:
> 10/19/15
>
> All,
>
> Version 4.0.0 was released in May, and it is now nearly November, i.e., 6
> months later.
>
> Using hg log -b stable -r release-4-0-0:: > stable.log
>
> There are just 74 changesets, but quite a few important fixes for
> segfaults, mis-calculated results, and regressions, as well as just
> documentation.  It would be nice to have some sort of fix for the crashes
> that lots of people seem to be having with OpenGL graphics, but I don't
> think we have an answer there so it isn't worth delaying.
>
> My vote is for a 4.0.1 bug fix release in November.

What should be done about the packages that go with the MXE releases?
Was there any consensus about what versions to use for that?  Should we:

1) use the exact same versions released with 4.0.0 (unfair, why don't the
packages get a chance for fix their issues)

2) the package last patch release for the version released with 4.0.0 (but
most OF packages don't follow core in only accepting regression fixes in
those patch releases)

3) the last release of each package (not great if we want to extend the
backwards compatible promise to the packages in the MXE distribution)
4) let the individual package maintainers decide.  After all they should know which package release fits Octave-4.0.1 the best.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

Carnë Draug
In reply to this post by John W. Eaton
On 20 October 2015 at 00:28, John W. Eaton <[hidden email]> wrote:

> On 10/19/2015 12:09 PM, Carnë Draug wrote:
>>
>> On 19 October 2015 at 16:19, Rik <[hidden email]> wrote:
>> [...]
>>
>> What should be done about the packages that go with the MXE releases?
>> Was there any consensus about what versions to use for that?  Should we:
>
> [...]
> For the Windows binary I'll use whatever packages you decide are best. I
> have no strong opinion about that, except that it's probably best to err on
> the side of stability, whatever that means.  How to decide that might vary
> from package to package.
>

I went through the list of packages, and their new releases.  Here's what
I found.

TL;DR:

* update the image, netcdf, stk, and generate_html packages
* do not update strings, nurbs, and tsa
* ask package maintainers for control, io, and ltfat
* all other packages have not been updated since

And now with mode details:

control:
  * Octave released with 2.8.1
  * new releases are 2.8.2, to 2.8.5
  * they fix several bugs, add new functions, and add new features
  * to many changes and too specific for me to judge

generate_html:
  * Octave released with 0.1.8
  * new release 0.1.9
  * The main use of this package is generation of the html for package
    releases of Octave Forge.  Because of this, its main users are
    Octave Forge developers.
  * Its users are most likely installing the package themselves so changes
    here shouldn't make much difference.
  * The package is almost useless unless on the very last release since
    I will reject releases otherwise (the generated html needs to match
    the rest of the website).
  * update to 0.1.9

image:
  * octave released with 2.4.0
  * last release is 2.4.1 (from the package stable branch)
  * only fixes regressions and a segfault
  * all other changes to the package have gone into the package default
    branch so are not released.
  * update to 2.4.1

io
  * octave released with 2.2.7
  * new releases are 2.2.8 to 2.2.11
  * fix several bugs, adds new features
  * to many changes and too specific for me to judge

ltfat
  * octave released with 2.1.0
  * new release 2.1.1
  * adds a bunch of new functions.  The NEWS file suggests that's everything
    but the logs of the repository show many other changes.
  * probably should not be updated but ask the package maintainer.

netcdf
  * octave released with 1.0.6
  * new release 1.0.7
  * the only change on the new release is required for MXE cross-compilation.
    This change was already applied on the 1.0.6 released with Octave anyway,
    so there will actually be no change.
  * update to 1.0.7

nurbs
  * octave released with 1.3.9
  * new release 1.3.10
  * includes a patch require for compatibility with Octave 4.0 but that's
    already included in the patched package in Octave.
  * has several other changes, including "changed the format of geopdes files",
    and change of behaviour "return an error if a point is outside the knotspan"
  * do not update

stk
  * octave released with 2.3.0
  * new released 2.3.1 to 2.3.3
  * several minor bug fixes which seem fine
  * update to 2.3.3 but check with package maintainer

strings
  * octave released with 1.1.0
  * new release 1.2.0
  * the update rewrites one function and removes two.
  * One of removed functions is strjoin which is required to play nice with
    Octave 4.0.0.  However, the version with Octave is patched to remove
    this function.
  * do not update

tsa
  * octave released with 4.2.9
  * new release is 4.3.2
  * most of the changes are build options, and compatibility with new Matlab
  * there's a documentation change and a small optimization to skip
    computations in specific case
  * do not update

No new version since Octave 4.0.0 release, keep as is:

  communications-1.2.1
  database-2.3.2
  dataframe-1.1.0
  data-smoothing-1.3.0
  dicom-0.1.1
  financial-0.4.0
  fits-1.0.5
  fl-core-1.0.0
  fuzzy-logic-toolkit-0.4.5
  ga-0.10.0
  general-2.0.0
  geometry-2.0.0
  instrument-control-0.2.1
  linear-algebra-2.2.2
  lssa-0.1.2
  miscellaneous-1.2.1
  octcdf-1.1.8
  odepkg-0.8.5
  optim-1.4.1
  quaternion-2.4.0
  queueing-1.2.3
  signal-1.3.2
  sockets-1.2.0
  specfun-1.1.0
  splines-1.2.8
  statistics-1.2.4
  struct-1.0.11
  windows-1.2.1
  zenity-0.5.7

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

Lukas Reichlin-4

> On 27.10.2015, at 15:32, Carnë Draug <[hidden email]> wrote:
>
> On 20 October 2015 at 00:28, John W. Eaton <[hidden email]> wrote:
>> On 10/19/2015 12:09 PM, Carnë Draug wrote:
>>>
>>> On 19 October 2015 at 16:19, Rik <[hidden email]> wrote:
>>> [...]
>>>
>>> What should be done about the packages that go with the MXE releases?
>>> Was there any consensus about what versions to use for that?  Should we:
>>
>> [...]
>> For the Windows binary I'll use whatever packages you decide are best. I
>> have no strong opinion about that, except that it's probably best to err on
>> the side of stability, whatever that means.  How to decide that might vary
>> from package to package.
>>
>
> I went through the list of packages, and their new releases.  Here's what
> I found.
>
> TL;DR:
>
> * update the image, netcdf, stk, and generate_html packages
> * do not update strings, nurbs, and tsa
> * ask package maintainers for control, io, and ltfat
> * all other packages have not been updated since
>
> And now with mode details:
>
> control:
>  * Octave released with 2.8.1
>  * new releases are 2.8.2, to 2.8.5
>  * they fix several bugs, add new functions, and add new features
>  * to many changes and too specific for me to judge
>
> generate_html:
>  * Octave released with 0.1.8
>  * new release 0.1.9
>  * The main use of this package is generation of the html for package
>    releases of Octave Forge.  Because of this, its main users are
>    Octave Forge developers.
>  * Its users are most likely installing the package themselves so changes
>    here shouldn't make much difference.
>  * The package is almost useless unless on the very last release since
>    I will reject releases otherwise (the generated html needs to match
>    the rest of the website).
>  * update to 0.1.9
>
> image:
>  * octave released with 2.4.0
>  * last release is 2.4.1 (from the package stable branch)
>  * only fixes regressions and a segfault
>  * all other changes to the package have gone into the package default
>    branch so are not released.
>  * update to 2.4.1
>
> io
>  * octave released with 2.2.7
>  * new releases are 2.2.8 to 2.2.11
>  * fix several bugs, adds new features
>  * to many changes and too specific for me to judge
>
> ltfat
>  * octave released with 2.1.0
>  * new release 2.1.1
>  * adds a bunch of new functions.  The NEWS file suggests that's everything
>    but the logs of the repository show many other changes.
>  * probably should not be updated but ask the package maintainer.
>
> netcdf
>  * octave released with 1.0.6
>  * new release 1.0.7
>  * the only change on the new release is required for MXE cross-compilation.
>    This change was already applied on the 1.0.6 released with Octave anyway,
>    so there will actually be no change.
>  * update to 1.0.7
>
> nurbs
>  * octave released with 1.3.9
>  * new release 1.3.10
>  * includes a patch require for compatibility with Octave 4.0 but that's
>    already included in the patched package in Octave.
>  * has several other changes, including "changed the format of geopdes files",
>    and change of behaviour "return an error if a point is outside the knotspan"
>  * do not update
>
> stk
>  * octave released with 2.3.0
>  * new released 2.3.1 to 2.3.3
>  * several minor bug fixes which seem fine
>  * update to 2.3.3 but check with package maintainer
>
> strings
>  * octave released with 1.1.0
>  * new release 1.2.0
>  * the update rewrites one function and removes two.
>  * One of removed functions is strjoin which is required to play nice with
>    Octave 4.0.0.  However, the version with Octave is patched to remove
>    this function.
>  * do not update
>
> tsa
>  * octave released with 4.2.9
>  * new release is 4.3.2
>  * most of the changes are build options, and compatibility with new Matlab
>  * there's a documentation change and a small optimization to skip
>    computations in specific case
>  * do not update
>
> No new version since Octave 4.0.0 release, keep as is:
>
>  communications-1.2.1
>  database-2.3.2
>  dataframe-1.1.0
>  data-smoothing-1.3.0
>  dicom-0.1.1
>  financial-0.4.0
>  fits-1.0.5
>  fl-core-1.0.0
>  fuzzy-logic-toolkit-0.4.5
>  ga-0.10.0
>  general-2.0.0
>  geometry-2.0.0
>  instrument-control-0.2.1
>  linear-algebra-2.2.2
>  lssa-0.1.2
>  miscellaneous-1.2.1
>  octcdf-1.1.8
>  odepkg-0.8.5
>  optim-1.4.1
>  quaternion-2.4.0
>  queueing-1.2.3
>  signal-1.3.2
>  sockets-1.2.0
>  specfun-1.1.0
>  splines-1.2.8
>  statistics-1.2.4
>  struct-1.0.11
>  windows-1.2.1
>  zenity-0.5.7
>
> Carnë
>

Regarding the control package, I recommend the latest version, control-2.8.5.

Lukas


Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

jbect
In reply to this post by Carnë Draug
Le 27/10/2015 15:32, Carnë Draug a écrit :
> stk
> * octave released with 2.3.0
> * new released 2.3.1 to 2.3.3
> * several minor bug fixes which seem fine
> * update to 2.3.3 but check with package maintainer

I agree, please update to 2.3.3 if possible.

Actually, depending on when the release actually happens, I might even
have time for a 2.3.4 with some additional bug fixes.

@++
Julien


Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

John Donoghue-3
In reply to this post by Rik-4
> I went through the list of packages, and their new releases.  Here's what
I found.

> * update the image, netcdf, stk, and generate_html packages
> * do not update strings, nurbs, and tsa
> * ask package maintainers for control, io, and ltfat
> * all other packages have not been updated since
>
> And now with mode details:
>
> control:
>   * Octave released with 2.8.1
>   * new releases are 2.8.2, to 2.8.5
>   * they fix several bugs, add new functions, and add new features
>   * to many changes and too specific for me to judge
>
> generate_html:
>   * Octave released with 0.1.8
>   * new release 0.1.9
>   * The main use of this package is generation of the html for package
>     releases of Octave Forge.  Because of this, its main users are
>     Octave Forge developers.
>   * Its users are most likely installing the package themselves so changes
>     here shouldn't make much difference.
>   * The package is almost useless unless on the very last release since
>     I will reject releases otherwise (the generated html needs to match
>     the rest of the website).
>   * update to 0.1.9
>
> image:
>   * octave released with 2.4.0
>   * last release is 2.4.1 (from the package stable branch)
>   * only fixes regressions and a segfault
>   * all other changes to the package have gone into the package default
>     branch so are not released.
>   * update to 2.4.1
>
> io
>   * octave released with 2.2.7
>   * new releases are 2.2.8 to 2.2.11
>   * fix several bugs, adds new features
>   * to many changes and too specific for me to judge
>
> ltfat
>   * octave released with 2.1.0
>   * new release 2.1.1
>   * adds a bunch of new functions.  The NEWS file suggests that's
everything
>     but the logs of the repository show many other changes.
>   * probably should not be updated but ask the package maintainer.
>
> netcdf
>   * octave released with 1.0.6
>   * new release 1.0.7
>   * the only change on the new release is required for MXE
cross-compilation.
>     This change was already applied on the 1.0.6 released with Octave
anyway,
>     so there will actually be no change.
>   * update to 1.0.7
>
> nurbs
>   * octave released with 1.3.9
>   * new release 1.3.10
>   * includes a patch require for compatibility with Octave 4.0 but that's
>     already included in the patched package in Octave.
>   * has several other changes, including "changed the format of geopdes
files",
>     and change of behaviour "return an error if a point is outside the
knotspan"

>   * do not update
>
> stk
>   * octave released with 2.3.0
>   * new released 2.3.1 to 2.3.3
>   * several minor bug fixes which seem fine
>   * update to 2.3.3 but check with package maintainer
>
> strings
>   * octave released with 1.1.0
>   * new release 1.2.0
>   * the update rewrites one function and removes two.
>   * One of removed functions is strjoin which is required to play nice
with
>     Octave 4.0.0.  However, the version with Octave is patched to remove
>     this function.
>   * do not update
>
> tsa
>   * octave released with 4.2.9
>   * new release is 4.3.2
>   * most of the changes are build options, and compatibility with new
Matlab

>   * there's a documentation change and a small optimization to skip
>     computations in specific case
>   * do not update
>
> No new version since Octave 4.0.0 release, keep as is:
>
>   communications-1.2.1
>   database-2.3.2
>   dataframe-1.1.0
>   data-smoothing-1.3.0
>   dicom-0.1.1
>   financial-0.4.0
>   fits-1.0.5
>   fl-core-1.0.0
>   fuzzy-logic-toolkit-0.4.5
>   ga-0.10.0
>   general-2.0.0
>   geometry-2.0.0
>   instrument-control-0.2.1
>   linear-algebra-2.2.2
>   lssa-0.1.2
>   miscellaneous-1.2.1
>   octcdf-1.1.8
>   odepkg-0.8.5
>   optim-1.4.1
>   quaternion-2.4.0
>   queueing-1.2.3
>   signal-1.3.2
>   sockets-1.2.0
>   specfun-1.1.0
>   splines-1.2.8
>   statistics-1.2.4
>   struct-1.0.11
>   windows-1.2.1
>   zenity-0.5.7
>
> Carn?
>


I have been trying to keep the mxe-octave repo (in terms of the version
numbers that will be packaged by default if someone downloads mxe and
compiles it) up to date with the current release of any package that appears
in the octave-maintainers announcements

So my vote would be 3.




Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

John W. Eaton
Administrator
On 10/27/2015 01:32 PM, JohnD wrote:
>> I went through the list of packages, and their new releases.  Here's what
> I found.
>
> I have been trying to keep the mxe-octave repo (in terms of the version
> numbers that will be packaged by default if someone downloads mxe and
> compiles it) up to date with the current release of any package that appears
> in the octave-maintainers announcements
>
> So my vote would be 3.

For a bug-fixing stable release, should we really be updating
dependencies, or should we just stick with what we used to build the
prior stable release unless we know of critical bugs that should be fixed?

jwe


Reply | Threaded
Open this post in threaded view
|

RE: Time for a 4.0.1 bug fix release?

John Donoghue-3


> -----Original Message-----
> From: John W. Eaton [mailto:[hidden email]]
> Sent: Tuesday, October 27, 2015 3:56 PM
> To: JohnD; [hidden email]
> Cc: [hidden email]
> Subject: Re: Time for a 4.0.1 bug fix release?
>
> On 10/27/2015 01:32 PM, JohnD wrote:
> >> I went through the list of packages, and their new releases.  Here's
> >> what
> > I found.
> >
> > I have been trying to keep the mxe-octave repo (in terms of the
> > version numbers that will be packaged by default if someone downloads
> > mxe and compiles it) up to date with the current release of any
> > package that appears in the octave-maintainers announcements
> >
> > So my vote would be 3.
>
> For a bug-fixing stable release, should we really be updating
dependencies, or
> should we just stick with what we used to build the prior stable release
unless we
> know of critical bugs that should be fixed?
>
> jwe


I had stopped updating major versions on most libraries, build tools etc
with the exception of minor releases/bugfixes

Except for octaveforge packages - which havent most of the updates for
octaveforge packages been mainly catching up on octave 4 ?


Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

Carnë Draug
On 27 October 2015 at 21:07, JohnD <[hidden email]> wrote:
> [...]
>
> Except for octaveforge packages - which havent most of the updates for
> octaveforge packages been mainly catching up on octave 4 ?

I don't think so.  There is a fair amount of bug fixing but most are not
related to Octave 4.0.  There's also new functions and features and those
have definitely nothing to do with Octave 4.0.

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: Time for a 4.0.1 bug fix release?

Julien Bect
In reply to this post by jbect
Please update the stk package to 2.3.4 for the upcoming bugfix release.

@++
Julien
12