4.4 Release Progress

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

4.4 Release Progress

John W. Eaton
Administrator
This morning, I added pre-release and release versions to the bug
tracker, removed functions deprecated in 4.2 from the default branch,
and updated the release checklist on the wiki with the current status.
Other than actually making the release, the following items remain:

   Identify Bugs which *must* be fixed prior to release

     Review bugs on tracker for possible inclusion in list
     Review bugs and update to correct category, such as Patch submitted
     See Bug Fix List - 4.4.0 Release

   Clear all bugs identified as must-fix

     In progress : Variable Editor bugs

   Verify 'make check' is passing

     Start discussion on octave-maintainers list about which failing
tests must be fixed
     Identify and fix any tests determined critical in step above

The bug list is here:

   https://wiki.octave.org/Bug_Fix_List_-_4.4.0_Release#Variable_Editor_Bugs


jwe

Reply | Threaded
Open this post in threaded view
|

Re: 4.4 Release Progress

Mike Miller-4
On Sat, Apr 07, 2018 at 12:32:46 -0400, John W. Eaton wrote:
> This morning, I added pre-release and release versions to the bug tracker,
> removed functions deprecated in 4.2 from the default branch, and updated the
> release checklist on the wiki with the current status. Other than actually
> making the release, the following items remain:

The shared library version numbers and the OCTAVE_API_VERSION need to be
updated before the release as well.

Are we planning on doing a release candidate or two as usual before the
actual release?

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 4.4 Release Progress

John W. Eaton
Administrator
On 04/07/2018 03:26 PM, Mike Miller wrote:
> On Sat, Apr 07, 2018 at 12:32:46 -0400, John W. Eaton wrote:
>> This morning, I added pre-release and release versions to the bug tracker,
>> removed functions deprecated in 4.2 from the default branch, and updated the
>> release checklist on the wiki with the current status. Other than actually
>> making the release, the following items remain:
>
> The shared library version numbers and the OCTAVE_API_VERSION need to be
> updated before the release as well.

OK, I added those items to the list on the wiki.

> Are we planning on doing a release candidate or two as usual before the
> actual release?

Yes.  I already added a 4.3.90 version number in the bug tracker.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: 4.4 Release Progress

Mike Miller-4
On Sat, Apr 07, 2018 at 15:37:21 -0400, John W. Eaton wrote:
> Yes.  I already added a 4.3.90 version number in the bug tracker.

So I take it you like the idea of using the x.y.9x numbers for
alpha/beta/rc/whatever-you-want-to-call-it?

I was thinking about this again, and it doesn't quite follow your ideal
of the version number being completely unambiguous. With Octave 5.0.0,
if I remember right, you are planning on tagging 5.1.0 as a release,
then immediately incrementing the version to 5.1.1 for stable bug fixes.
So there will be exactly one revision in the hg history that has a
version number of 5.1.0.

Do you think it's important to do the same for release candidates? IOW,
should there be exactly one revision in the hg history when the version
number is 4.3.90?

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 4.4 Release Progress

John W. Eaton
Administrator
On 04/07/2018 05:12 PM, Mike Miller wrote:
> On Sat, Apr 07, 2018 at 15:37:21 -0400, John W. Eaton wrote:
>> Yes.  I already added a 4.3.90 version number in the bug tracker.
>
> So I take it you like the idea of using the x.y.9x numbers for
> alpha/beta/rc/whatever-you-want-to-call-it?

We've used that before, and I prefer it to appending -rcN to the version
number.

> I was thinking about this again, and it doesn't quite follow your ideal
> of the version number being completely unambiguous. With Octave 5.0.0,
> if I remember right, you are planning on tagging 5.1.0 as a release,
> then immediately incrementing the version to 5.1.1 for stable bug fixes.
> So there will be exactly one revision in the hg history that has a
> version number of 5.1.0.

I hadn't really thought about it, but I guess it makes sense that there
would be just one revision in the hg archive corresponding to actual
releases.  Then X.Y.1 is the number for subsequent development of the
X.Y.0 release.

> Do you think it's important to do the same for release candidates? IOW,
> should there be exactly one revision in the hg history when the version
> number is 4.3.90?

I don't know that it matters as much.  But if we did that, then each
release candidate would be an even number?  4.3.9{0,2,4,...} are release
candidates and 4.3.9{1,3,5,...} would be used for and changes in
between?  Hmm.  I don't really know what is best.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: 4.4 Release Progress

Mike Miller-4
On Sat, Apr 07, 2018 at 19:12:20 -0400, John W. Eaton wrote:
> I don't know that it matters as much.  But if we did that, then each release
> candidate would be an even number?  4.3.9{0,2,4,...} are release candidates
> and 4.3.9{1,3,5,...} would be used for and changes in between?  Hmm.  I
> don't really know what is best.

I don't either. It's probably not that important for release candidates
anyway, since they are hopefully short-lived. Maybe not overthink it for
now, just have release candidates 4.3.9{0,1,2,...}.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 4.4 Release Progress

Daniel Sebald
Got a small change worth adding to 4.4:

https://savannah.gnu.org/bugs/?53410#comment10

It will prevent an annoying loss of focus that I'm sure someone would
otherwise write a bug report for.

Dan