Plans for Octave 6.1 release

classic Classic list List threaded Threaded
92 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Plans for Octave 6.1 release

Rik-4
All,

We are trying to get in the habit of making more frequent releases of
Octave, at least yearly.  Traditionally the release is in late December or
early January.  I have worked as the release manager for the last four
releases, but don't have time to reprise that role this year.

The first question is whether there is someone on the Maintainer's list who
does have the time and inclination to be the manager this year?

The checklist of instructions is at etc/RELEASE.CHECKLIST and the
accompanying bug fix template is at etc/RELEASE.BUG_FIX_LIST. 
Traditionally I have placed these as pages on the Octave Wiki at
https://wiki.octave.org/Category:Development so that everyone could see the
status, and make changes without requiring excessive permissions.  I have
started things off by performing action item #1 : updating gnulib repo.

If no one has enough time to be manager then we will fall back to doing a
point release in January with the expectation that it will require a minor
release shortly thereafter because there has been less checking.  This
would be in keeping with modern practice which is to release every six
weeks and rely on users for bug testing.  The Octave code base, even on the
development branch, always compiles and almost always passes 'make check'
so this is acceptable.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Plans for Octave 6.1 release

mmuetzel
Am 06. Dezember 2019 um 23:01 Uhr schrieb "Rik":
> The checklist of instructions is at etc/RELEASE.CHECKLIST and the
> accompanying bug fix template is at etc/RELEASE.BUG_FIX_LIST. 
> Traditionally I have placed these as pages on the Octave Wiki at
> https://wiki.octave.org/Category:Development so that everyone could see the
> status, and make changes without requiring excessive permissions.  I have
> started things off by performing action item #1 : updating gnulib repo.

That doesn't seem to have worked. There was activity in their git repository during the last 8 months:
http://git.savannah.gnu.org/gitweb/?p=gnulib.git

I don't know how to import those changes to our hg sub-repo though.

Markus


Reply | Threaded
Open this post in threaded view
|

Re: Plans for Octave 6.1 release

mmuetzel
Am 07. Dezember 2019 um 21:49 Uhr schrieb "Markus Mützel":

> Am 06. Dezember 2019 um 23:01 Uhr schrieb "Rik":
> > The checklist of instructions is at etc/RELEASE.CHECKLIST and the
> > accompanying bug fix template is at etc/RELEASE.BUG_FIX_LIST. 
> > Traditionally I have placed these as pages on the Octave Wiki at
> > https://wiki.octave.org/Category:Development so that everyone could see the
> > status, and make changes without requiring excessive permissions.  I have
> > started things off by performing action item #1 : updating gnulib repo.
>
> That doesn't seem to have worked. There was activity in their git repository during the last 8 months:
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git
>
> I don't know how to import those changes to our hg sub-repo though.

I pushed the following change to the instructions:
http://hg.savannah.gnu.org/hgweb/octave/rev/873ef98668d1

This worked correctly for me locally. But I haven't actually pushed any changes in case this isn't the preferred procedure.

It might also be possible to get rid of the first lengthy hg convert of the complete repository (~1 hour on my hardware). But I'm not familiar with git. It would probably work if we could derive the information for the splicemap directly from the git repository.

Markus

Reply | Threaded
Open this post in threaded view
|

Re: Plans for Octave 6.1 release

siko1056
In reply to this post by Rik-4
On 12/7/19 7:01 AM, Rik wrote:

> All,
>
> We are trying to get in the habit of making more frequent releases of
> Octave, at least yearly.  Traditionally the release is in late December or
> early January.  I have worked as the release manager for the last four
> releases, but don't have time to reprise that role this year.
>
> The first question is whether there is someone on the Maintainer's list who
> does have the time and inclination to be the manager this year?
>
> The checklist of instructions is at etc/RELEASE.CHECKLIST and the
> accompanying bug fix template is at etc/RELEASE.BUG_FIX_LIST. 
> Traditionally I have placed these as pages on the Octave Wiki at
> https://wiki.octave.org/Category:Development so that everyone could see the
> status, and make changes without requiring excessive permissions.  I have
> started things off by performing action item #1 : updating gnulib repo.
>
> If no one has enough time to be manager then we will fall back to doing a
> point release in January with the expectation that it will require a minor
> release shortly thereafter because there has been less checking.  This
> would be in keeping with modern practice which is to release every six
> weeks and rely on users for bug testing.  The Octave code base, even on the
> development branch, always compiles and almost always passes 'make check'
> so this is acceptable.
>
> --Rik
>


Dear Rik,

Your efforts for GNU Octave are really outstanding and I am very
thankful that you managed the passed releases with lots of work,
passion, and care for the details.  The same thanks go as well to many
other contributors who almost every day ensure my "hg pull" command to
grab fixes for bugs and many useful improvements for free (as in speech
and beer) ;-)  Please resist from managing this release if your time is
too limited.

You and Markus already got things started.  Additionally, I overhauled
the wiki [1] and hope to have introduced a useful "innovation" by using
"clever" linking to Savannah to track the state of the bugs, rather than
duplicating the data in a separate wiki page, that gets outdated too
fast and is hard to maintain consistently.  In the past releases I
quickly lost the overview with this approach.

After you raised the bar by your great work on the past releases, Rik, I
think hardly anyone dares to step into your shoes ^^  By reviewing [1],
I am able to perform most of the organizational steps myself.  Thus I
hope others join into working on [1] until the bottom of that page is
reached.

When it comes to build release candidates, my machine is able to do
this.  But I think jwe has to sign and upload these builds to [2], right?

My personal expectation is no 6.1 release before February 2020 [3].  But
as 5.1.0 is already long time ago, I vote for another 5.2.0 stable
release before Christmas, followed by efforts to release 6.1.0.  On the
stable branch, there are

   hg log -r "release-5-1-0:" -b stable | grep "changeset" | wc -l

104 more or less important changes accumulated over 10 months users are
waiting for.  This stable release does not need that much effort [1], as
it is stable, and I can prepare the stable branch for 5.2.0.  Opinions?

Best,
Kai


[1] https://wiki.octave.org/6.1_Release_Checklist
[2] https://ftp.gnu.org/gnu/octave/
[3]
https://github.com/octave-de/octave_slides/blob/00a00e89e79a13d4c42ef6b12491ff2107d69a64/jupyter/mailing_list_activity.ipynb

Reply | Threaded
Open this post in threaded view
|

Re: Plans for Octave 6.1 release

Doug Stewart-4


On Tue, Dec 10, 2019 at 5:59 AM Kai Torben Ohlhus <[hidden email]> wrote:
On 12/7/19 7:01 AM, Rik wrote:
> All,
>
> We are trying to get in the habit of making more frequent releases of
> Octave, at least yearly.  Traditionally the release is in late December or
> early January.  I have worked as the release manager for the last four
> releases, but don't have time to reprise that role this year.
>
> The first question is whether there is someone on the Maintainer's list who
> does have the time and inclination to be the manager this year?
>
> The checklist of instructions is at etc/RELEASE.CHECKLIST and the
> accompanying bug fix template is at etc/RELEASE.BUG_FIX_LIST. 
> Traditionally I have placed these as pages on the Octave Wiki at
> https://wiki.octave.org/Category:Development so that everyone could see the
> status, and make changes without requiring excessive permissions.  I have
> started things off by performing action item #1 : updating gnulib repo.
>
> If no one has enough time to be manager then we will fall back to doing a
> point release in January with the expectation that it will require a minor
> release shortly thereafter because there has been less checking.  This
> would be in keeping with modern practice which is to release every six
> weeks and rely on users for bug testing.  The Octave code base, even on the
> development branch, always compiles and almost always passes 'make check'
> so this is acceptable.
>
> --Rik
>


Dear Rik,

Your efforts for GNU Octave are really outstanding and I am very
thankful that you managed the passed releases with lots of work,
passion, and care for the details.  The same thanks go as well to many
other contributors who almost every day ensure my "hg pull" command to
grab fixes for bugs and many useful improvements for free (as in speech
and beer) ;-)  Please resist from managing this release if your time is
too limited.

You and Markus already got things started.  Additionally, I overhauled
the wiki [1] and hope to have introduced a useful "innovation" by using
"clever" linking to Savannah to track the state of the bugs, rather than
duplicating the data in a separate wiki page, that gets outdated too
fast and is hard to maintain consistently.  In the past releases I
quickly lost the overview with this approach.

After you raised the bar by your great work on the past releases, Rik, I
think hardly anyone dares to step into your shoes ^^  By reviewing [1],
I am able to perform most of the organizational steps myself.  Thus I
hope others join into working on [1] until the bottom of that page is
reached.

When it comes to build release candidates, my machine is able to do
this.  But I think jwe has to sign and upload these builds to [2], right?

My personal expectation is no 6.1 release before February 2020 [3].  But
as 5.1.0 is already long time ago, I vote for another 5.2.0 stable
release before Christmas, followed by efforts to release 6.1.0.  On the
stable branch, there are

   hg log -r "release-5-1-0:" -b stable | grep "changeset" | wc -l

104 more or less important changes accumulated over 10 months users are
waiting for.  This stable release does not need that much effort [1], as
it is stable, and I can prepare the stable branch for 5.2.0.  Opinions?

Best,
Kai


[1] https://wiki.octave.org/6.1_Release_Checklist
[2] https://ftp.gnu.org/gnu/octave/
[3]
https://github.com/octave-de/octave_slides/blob/00a00e89e79a13d4c42ef6b12491ff2107d69a64/jupyter/mailing_list_activity.ipynb


I agree very strongly that we should have a 5.2.0.
I say this because:
1) there are many fixes  on stable, that are not released. (and not many new bug reports)
2) there are many new bug reports about developer branch i.e. it is not very stable yet.  
signed:
Doug (who wishes he could be more helpful)


--
DASCertificate for 206392

Reply | Threaded
Open this post in threaded view
|

Re: Plans for Octave 6.1 release

mmuetzel
In reply to this post by siko1056
Am 10. Dezember 2019 um 11:58 Uhr schrieb "Kai Torben Ohlhus":

> My personal expectation is no 6.1 release before February 2020 [3].  But
> as 5.1.0 is already long time ago, I vote for another 5.2.0 stable
> release before Christmas, followed by efforts to release 6.1.0.  On the
> stable branch, there are
>
>    hg log -r "release-5-1-0:" -b stable | grep "changeset" | wc -l
>
> 104 more or less important changes accumulated over 10 months users are
> waiting for.  This stable release does not need that much effort [1], as
> it is stable, and I can prepare the stable branch for 5.2.0.  Opinions?

I personally don't know how I feel about a 5.2 release. There probably are bugs in the stable branch that haven't been there in Octave 5.1 and that have been fixed on the development branch only (e.g. bug #55908 [1]).

We are not many developers. So I don't know whether we shouldn't better spend our limited time to get the default branch ready instead of fixing issues on the soon to be deprecated current stable branch.

But I won't hold anyone back if we agree on delaying Octave 6 for another dot release.

Markus

[1]: https://savannah.gnu.org/bugs/index.php?55908

Reply | Threaded
Open this post in threaded view
|

Re: Plans for Octave 6.1 release

Pantxo
mmuetzel wrote

> Am 10. Dezember 2019 um 11:58 Uhr schrieb "Kai Torben Ohlhus":
>> My personal expectation is no 6.1 release before February 2020 [3].  But
>> as 5.1.0 is already long time ago, I vote for another 5.2.0 stable
>> release before Christmas, followed by efforts to release 6.1.0.  On the
>> stable branch, there are
>>
>>    hg log -r "release-5-1-0:" -b stable | grep "changeset" | wc -l
>>
>> 104 more or less important changes accumulated over 10 months users are
>> waiting for.  This stable release does not need that much effort [1], as
>> it is stable, and I can prepare the stable branch for 5.2.0.  Opinions?
>
> I personally don't know how I feel about a 5.2 release. There probably are
> bugs in the stable branch that haven't been there in Octave 5.1 and that
> have been fixed on the development branch only (e.g. bug #55908 [1]).
>
> We are not many developers. So I don't know whether we shouldn't better
> spend our limited time to get the default branch ready instead of fixing
> issues on the soon to be deprecated current stable branch.
> [1]: https://savannah.gnu.org/bugs/index.php?55908

I second this opinion: I am in favor of focusing on Octave 6.1 and releasing
soon. This  will involve much testing, yes, but will avoid having to do the
job twice. Then, we can do a 6.2 release soon after 6.1 to fix critical
uncovered bugs.

As usual I won't be of any help in most repo. administration tasks, but I'll
do my best to help track regressions (in the graphics system at least).

Pantxo  



--
Sent from: https://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Updating gnulib sub-repository (was: Plans for Octave 6.1 release)

mmuetzel
In reply to this post by mmuetzel
Am 08. Dezember 2019 um 15:12 Uhr schrieb "Markus Mützel":

> Am 07. Dezember 2019 um 21:49 Uhr schrieb "Markus Mützel":
> > Am 06. Dezember 2019 um 23:01 Uhr schrieb "Rik":
> > > The checklist of instructions is at etc/RELEASE.CHECKLIST and the
> > > accompanying bug fix template is at etc/RELEASE.BUG_FIX_LIST. 
> > > Traditionally I have placed these as pages on the Octave Wiki at
> > > https://wiki.octave.org/Category:Development so that everyone could see the
> > > status, and make changes without requiring excessive permissions.  I have
> > > started things off by performing action item #1 : updating gnulib repo.
> >
> > That doesn't seem to have worked. There was activity in their git repository during the last 8 months:
> > http://git.savannah.gnu.org/gitweb/?p=gnulib.git
> >
> > I don't know how to import those changes to our hg sub-repo though.
>
> I pushed the following change to the instructions:
> http://hg.savannah.gnu.org/hgweb/octave/rev/873ef98668d1
>
> This worked correctly for me locally. But I haven't actually pushed any changes in case this isn't the preferred procedure.
>
> It might also be possible to get rid of the first lengthy hg convert of the complete repository (~1 hour on my hardware). But I'm not familiar with git. It would probably work if we could derive the information for the splicemap directly from the git repository.

The most important step of the procedure is still missing:
I don't how to push to the gnulib sub-repo.

Markus

Reply | Threaded
Open this post in threaded view
|

Re: Updating gnulib sub-repository (was: Plans for Octave 6.1 release)

Rik-4
On 12/10/2019 10:59 AM, "Markus Mützel" wrote:

> Am 08. Dezember 2019 um 15:12 Uhr schrieb "Markus Mützel":
>> Am 07. Dezember 2019 um 21:49 Uhr schrieb "Markus Mützel":
>>> Am 06. Dezember 2019 um 23:01 Uhr schrieb "Rik":
>>>> The checklist of instructions is at etc/RELEASE.CHECKLIST and the
>>>> accompanying bug fix template is at etc/RELEASE.BUG_FIX_LIST. 
>>>> Traditionally I have placed these as pages on the Octave Wiki at
>>>> https://wiki.octave.org/Category:Development so that everyone could see the
>>>> status, and make changes without requiring excessive permissions.  I have
>>>> started things off by performing action item #1 : updating gnulib repo.
>>> That doesn't seem to have worked. There was activity in their git repository during the last 8 months:
>>> http://git.savannah.gnu.org/gitweb/?p=gnulib.git
>>>
>>> I don't know how to import those changes to our hg sub-repo though.
>> I pushed the following change to the instructions:
>> http://hg.savannah.gnu.org/hgweb/octave/rev/873ef98668d1
>>
>> This worked correctly for me locally. But I haven't actually pushed any changes in case this isn't the preferred procedure.
>>
>> It might also be possible to get rid of the first lengthy hg convert of the complete repository (~1 hour on my hardware). But I'm not familiar with git. It would probably work if we could derive the information for the splicemap directly from the git repository.
> The most important step of the procedure is still missing:
> I don't how to push to the gnulib sub-repo.
>
> Markus

jwe or Mike probably know what the correct procedure is.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Octave 5.2.0 release

Rik-4
In reply to this post by mmuetzel
On 12/10/2019 04:38 AM, "Markus Mützel" wrote:

> Am 10. Dezember 2019 um 11:58 Uhr schrieb "Kai Torben Ohlhus":
>> My personal expectation is no 6.1 release before February 2020 [3].  But
>> as 5.1.0 is already long time ago, I vote for another 5.2.0 stable
>> release before Christmas, followed by efforts to release 6.1.0.  On the
>> stable branch, there are
>>
>>    hg log -r "release-5-1-0:" -b stable | grep "changeset" | wc -l
>>
>> 104 more or less important changes accumulated over 10 months users are
>> waiting for.  This stable release does not need that much effort [1], as
>> it is stable, and I can prepare the stable branch for 5.2.0.  Opinions?
> I personally don't know how I feel about a 5.2 release. There probably are bugs in the stable branch that haven't been there in Octave 5.1 and that have been fixed on the development branch only (e.g. bug #55908 [1]).
>
> We are not many developers. So I don't know whether we shouldn't better spend our limited time to get the default branch ready instead of fixing issues on the soon to be deprecated current stable branch.
>
> But I won't hold anyone back if we agree on delaying Octave 6 for another dot release.

A new stable release should be very easy and thus not distracting for core
developers.  I have no objection if we do it, nor any strong leaning to do
it.  If it exposes new bugs, they will be fixed by the the 6.1 release in
another month or so.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Plans for Octave 6.1 release

Rik-4
In reply to this post by siko1056
On 12/10/2019 02:58 AM, Kai Torben Ohlhus wrote:

> Dear Rik,
> Your efforts for GNU Octave are really outstanding and I am very
> thankful that you managed the passed releases with lots of work,
> passion, and care for the details.  The same thanks go as well to many
> other contributors who almost every day ensure my "hg pull" command to
> grab fixes for bugs and many useful improvements for free (as in speech
> and beer) ;-)  Please resist from managing this release if your time is
> too limited.
>
> You and Markus already got things started.

I completed a grammar check and spell check of the documentation today.  I
marked those as done at
https://wiki.octave.org/6.1_Release_Checklist#Review_documentation.

>  Additionally, I overhauled
> the wiki [1] and hope to have introduced a useful "innovation" by using
> "clever" linking to Savannah to track the state of the bugs, rather than
> duplicating the data in a separate wiki page, that gets outdated too
> fast and is hard to maintain consistently.  In the past releases I
> quickly lost the overview with this approach.

Thank you, I think that system will work better than what we have had in
the past.

> After you raised the bar by your great work on the past releases, Rik, I
> think hardly anyone dares to step into your shoes ^^  By reviewing [1],
> I am able to perform most of the organizational steps myself.  Thus I
> hope others join into working on [1] until the bottom of that page is
> reached.
>
> When it comes to build release candidates, my machine is able to do
> this.  But I think jwe has to sign and upload these builds to [2], right?

Yes, he usually takes care of that and uploading them to alpha.gnu.org.

>
> My personal expectation is no 6.1 release before February 2020 [3].
Your probably right, but I will still hope for something in January.  Just
after New Year's the copyright statements could be updated which would make
a natural release point.

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: Updating gnulib sub-repository (was: Plans for Octave 6.1 release)

siko1056
In reply to this post by Rik-4
On 12/11/19 4:01 AM, Rik wrote:

> On 12/10/2019 10:59 AM, "Markus Mützel" wrote:
>> Am 08. Dezember 2019 um 15:12 Uhr schrieb "Markus Mützel":
>>> Am 07. Dezember 2019 um 21:49 Uhr schrieb "Markus Mützel":
>>>> Am 06. Dezember 2019 um 23:01 Uhr schrieb "Rik":
>>>>> The checklist of instructions is at etc/RELEASE.CHECKLIST and the
>>>>> accompanying bug fix template is at etc/RELEASE.BUG_FIX_LIST. 
>>>>> Traditionally I have placed these as pages on the Octave Wiki at
>>>>> https://wiki.octave.org/Category:Development so that everyone could see the
>>>>> status, and make changes without requiring excessive permissions.  I have
>>>>> started things off by performing action item #1 : updating gnulib repo.
>>>> That doesn't seem to have worked. There was activity in their git repository during the last 8 months:
>>>> http://git.savannah.gnu.org/gitweb/?p=gnulib.git
>>>>
>>>> I don't know how to import those changes to our hg sub-repo though.
>>> I pushed the following change to the instructions:
>>> http://hg.savannah.gnu.org/hgweb/octave/rev/873ef98668d1
>>>
>>> This worked correctly for me locally. But I haven't actually pushed any changes in case this isn't the preferred procedure.
>>>
>>> It might also be possible to get rid of the first lengthy hg convert of the complete repository (~1 hour on my hardware). But I'm not familiar with git. It would probably work if we could derive the information for the splicemap directly from the git repository.
>> The most important step of the procedure is still missing:
>> I don't how to push to the gnulib sub-repo.
>>
>> Markus
>
> jwe or Mike probably know what the correct procedure is.
>
> --Rik
>


Maybe the gnulib hg subrepo can be obsoleted for 6.1, see my changeset
in bug #57044 [1].

Best,
Kai

[1] https://savannah.gnu.org/bugs/index.php?57044#comment10

Reply | Threaded
Open this post in threaded view
|

Re: Octave 5.2.0 release

siko1056
In reply to this post by Rik-4
On 12/11/19 4:06 AM, Rik wrote:

> On 12/10/2019 04:38 AM, "Markus Mützel" wrote:
>> Am 10. Dezember 2019 um 11:58 Uhr schrieb "Kai Torben Ohlhus":
>>> My personal expectation is no 6.1 release before February 2020 [3].  But
>>> as 5.1.0 is already long time ago, I vote for another 5.2.0 stable
>>> release before Christmas, followed by efforts to release 6.1.0.  On the
>>> stable branch, there are
>>>
>>>    hg log -r "release-5-1-0:" -b stable | grep "changeset" | wc -l
>>>
>>> 104 more or less important changes accumulated over 10 months users are
>>> waiting for.  This stable release does not need that much effort [1], as
>>> it is stable, and I can prepare the stable branch for 5.2.0.  Opinions?
>> I personally don't know how I feel about a 5.2 release. There probably are bugs in the stable branch that haven't been there in Octave 5.1 and that have been fixed on the development branch only (e.g. bug #55908 [1]).
>>
>> We are not many developers. So I don't know whether we shouldn't better spend our limited time to get the default branch ready instead of fixing issues on the soon to be deprecated current stable branch.
>>
>> But I won't hold anyone back if we agree on delaying Octave 6 for another dot release.
>
> A new stable release should be very easy and thus not distracting for core
> developers.  I have no objection if we do it, nor any strong leaning to do
> it.  If it exposes new bugs, they will be fixed by the the 6.1 release in
> another month or so.
>
> --Rik
>

jwe and other developers, what do you think about a stable release?  I
think to be able to manage most steps of the release by myself, not
binding additional development power.  Stable is stable, just updating
dates and version numbers, that's it.  All work remains on Octave 6.1
beginning of 2020.

Kai

Reply | Threaded
Open this post in threaded view
|

Re: Octave 5.2.0 release

Torsten Lilge
On Thu, 2019-12-12 at 11:58 +0900, Kai Torben Ohlhus wrote:

> On 12/11/19 4:06 AM, Rik wrote:
> > On 12/10/2019 04:38 AM, "Markus Mützel" wrote:
> > > Am 10. Dezember 2019 um 11:58 Uhr schrieb "Kai Torben Ohlhus":
> > > > My personal expectation is no 6.1 release before February 2020
> > > > [3].  But
> > > > as 5.1.0 is already long time ago, I vote for another 5.2.0
> > > > stable
> > > > release before Christmas, followed by efforts to release
> > > > 6.1.0.  On the
> > > > stable branch, there are
> > > >
> > > >    hg log -r "release-5-1-0:" -b stable | grep "changeset" | wc
> > > > -l
> > > >
> > > > 104 more or less important changes accumulated over 10 months
> > > > users are
> > > > waiting for.  This stable release does not need that much effort
> > > > [1], as
> > > > it is stable, and I can prepare the stable branch for
> > > > 5.2.0.  Opinions?
> > > I personally don't know how I feel about a 5.2 release. There
> > > probably are bugs in the stable branch that haven't been there in
> > > Octave 5.1 and that have been fixed on the development branch only
> > > (e.g. bug #55908 [1]).
> > >
> > > We are not many developers. So I don't know whether we shouldn't
> > > better spend our limited time to get the default branch ready
> > > instead of fixing issues on the soon to be deprecated current
> > > stable branch.
> > >
> > > But I won't hold anyone back if we agree on delaying Octave 6 for
> > > another dot release.
> >
> > A new stable release should be very easy and thus not distracting
> > for core
> > developers.  I have no objection if we do it, nor any strong leaning
> > to do
> > it.  If it exposes new bugs, they will be fixed by the the 6.1
> > release in
> > another month or so.
> >
> > --Rik
> >
>
> jwe and other developers, what do you think about a stable release?  I
> think to be able to manage most steps of the release by myself, not
> binding additional development power.  Stable is stable, just updating
> dates and version numbers, that's it.  All work remains on Octave 6.1
> beginning of 2020.
>
> Kai

Kai, thanks for taking care of this. I woul like to vote for a stable
release since there are some important bug fixes for the gui in the
stable branch.

Torsten
 



Reply | Threaded
Open this post in threaded view
|

Re: Octave 5.2.0 release

John W. Eaton
Administrator
In reply to this post by Rik-4
On 12/10/19 1:06 PM, Rik wrote:

> On 12/10/2019 04:38 AM, "Markus Mützel" wrote:
>> Am 10. Dezember 2019 um 11:58 Uhr schrieb "Kai Torben Ohlhus":
>>> My personal expectation is no 6.1 release before February 2020 [3].  But
>>> as 5.1.0 is already long time ago, I vote for another 5.2.0 stable
>>> release before Christmas, followed by efforts to release 6.1.0.  On the
>>> stable branch, there are
>>>
>>>     hg log -r "release-5-1-0:" -b stable | grep "changeset" | wc -l
>>>
>>> 104 more or less important changes accumulated over 10 months users are
>>> waiting for.  This stable release does not need that much effort [1], as
>>> it is stable, and I can prepare the stable branch for 5.2.0.  Opinions?
>> I personally don't know how I feel about a 5.2 release. There probably are bugs in the stable branch that haven't been there in Octave 5.1 and that have been fixed on the development branch only (e.g. bug #55908 [1]).
>>
>> We are not many developers. So I don't know whether we shouldn't better spend our limited time to get the default branch ready instead of fixing issues on the soon to be deprecated current stable branch.
>>
>> But I won't hold anyone back if we agree on delaying Octave 6 for another dot release.
>
> A new stable release should be very easy and thus not distracting for core
> developers.  I have no objection if we do it, nor any strong leaning to do
> it.  If it exposes new bugs, they will be fixed by the the 6.1 release in
> another month or so.

I agree.  If we are going to do it, let's do it in the next week or so.
I should be able to prepare a release candidate and a set of Windows
binaries for testing this weekend.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Octave 5.2.0 release

siko1056
On 12/12/19 11:21 PM, John W. Eaton wrote:

> On 12/10/19 1:06 PM, Rik wrote:
>> On 12/10/2019 04:38 AM, "Markus Mützel" wrote:
>>> Am 10. Dezember 2019 um 11:58 Uhr schrieb "Kai Torben Ohlhus":
>>>> My personal expectation is no 6.1 release before February 2020 [3]. 
>>>> But
>>>> as 5.1.0 is already long time ago, I vote for another 5.2.0 stable
>>>> release before Christmas, followed by efforts to release 6.1.0.  On the
>>>> stable branch, there are
>>>>
>>>>     hg log -r "release-5-1-0:" -b stable | grep "changeset" | wc -l
>>>>
>>>> 104 more or less important changes accumulated over 10 months users are
>>>> waiting for.  This stable release does not need that much effort
>>>> [1], as
>>>> it is stable, and I can prepare the stable branch for 5.2.0.  Opinions?
>>> I personally don't know how I feel about a 5.2 release. There
>>> probably are bugs in the stable branch that haven't been there in
>>> Octave 5.1 and that have been fixed on the development branch only
>>> (e.g. bug #55908 [1]).
>>>
>>> We are not many developers. So I don't know whether we shouldn't
>>> better spend our limited time to get the default branch ready instead
>>> of fixing issues on the soon to be deprecated current stable branch.
>>>
>>> But I won't hold anyone back if we agree on delaying Octave 6 for
>>> another dot release.
>>
>> A new stable release should be very easy and thus not distracting for
>> core
>> developers.  I have no objection if we do it, nor any strong leaning
>> to do
>> it.  If it exposes new bugs, they will be fixed by the the 6.1 release in
>> another month or so.
>
> I agree.  If we are going to do it, let's do it in the next week or so.
> I should be able to prepare a release candidate and a set of Windows
> binaries for testing this weekend.
>
> jwe
>

By "release candidate" you mean 5.1.90 before 5.2.0?

Best,
Kai

Reply | Threaded
Open this post in threaded view
|

Re: Octave 5.2.0 release

John W. Eaton
Administrator
On 12/12/19 8:38 AM, Kai Torben Ohlhus wrote:

> By "release candidate" you mean 5.1.90 before 5.2.0?

Yes, I think it makes sense to do that even for a stable bug-fixing
release as a final check that "make dist" and the Windows builds work as
expected.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Plans for Octave 6.1 release

John W. Eaton
Administrator
In reply to this post by Rik-4
On 12/10/19 8:04 PM, Rik wrote:
> On 12/10/2019 02:58 AM, Kai Torben Ohlhus wrote:

>>   Additionally, I overhauled
>> the wiki [1] and hope to have introduced a useful "innovation" by using
>> "clever" linking to Savannah to track the state of the bugs, rather than
>> duplicating the data in a separate wiki page, that gets outdated too
>> fast and is hard to maintain consistently.  In the past releases I
>> quickly lost the overview with this approach.
>
> Thank you, I think that system will work better than what we have had in
> the past.

Yes, that looks good.

Although it is always a goal to reduce the number of open bug reports,
for this and future releases I would like to avoid the rush to rapidly
fix all bugs at the last minute before the release.  Doing that just
seems to introduce instability and causes further delay.  Instead, I
think it would be better to just aim for a release sometime in January
and then follow up with a bug fix release a month or two later.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Octave 5.2.0 release

siko1056
In reply to this post by John W. Eaton
On 12/12/19 11:21 PM, John W. Eaton wrote:
> I agree.  If we are going to do it, let's do it in the next week or so.
> I should be able to prepare a release candidate and a set of Windows
> binaries for testing this weekend.
>
> jwe
>

On 12/12/19 11:43 PM, John W. Eaton wrote:

> On 12/12/19 8:38 AM, Kai Torben Ohlhus wrote:
>
>> By "release candidate" you mean 5.1.90 before 5.2.0?
>
> Yes, I think it makes sense to do that even for a stable bug-fixing
> release as a final check that "make dist" and the Windows builds work as
> expected.
>
> jwe
>
>

You are right.  The version on stable is now bumped to 5.1.90 and
including Shared Library Versions for the weekend (Saturday, Dec. 14):

   https://hg.savannah.gnu.org/hgweb/octave/rev/230c20b02682

Now only a tag should be added and the built dist release candidate can
be uploaded to

   https://alpha.gnu.org/gnu/octave/

Later the MS Windows builds.  Thank you for your help.

Best,
Kai

Reply | Threaded
Open this post in threaded view
|

Re: Octave 5.2.0 release

siko1056
In reply to this post by John W. Eaton
On 12/12/19 11:43 PM, John W. Eaton wrote:

> On 12/12/19 8:38 AM, Kai Torben Ohlhus wrote:
>
>> By "release candidate" you mean 5.1.90 before 5.2.0?
>
> Yes, I think it makes sense to do that even for a stable bug-fixing
> release as a final check that "make dist" and the Windows builds work as
> expected.
>
> jwe
>


jwe and all,

currently I am uploading fresh builds of the stable branch 5.1.90,
including all 3x3 flavors of MXE and build logs to

   https://octave.space/stable_56dd7419d7aa/

This might take some time, but the most important ones

   octave-5.1.90-w64-*

are already there.  Was it possible to publish that release on

   https://alpha.gnu.org/gnu/octave/  ?

I would be happy to announce a final regression test period from January
15 to 31 followed by a minor Octave 5.2.0 release, if no bad regressions
were discovered in that time.  Then all focus goes back to Octave 6.

A final note about the year 2020 change:  Basically, on Octave 5.2.0
there was no development in 2020.  Thus we might skip touching all
headers and just adapt the date in the most important places indicating
the year of the 5.2.0 release.

Kai

12345