uploading and tagging version 5.2.0?

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

uploading and tagging version 5.2.0?

Mike Miller-4
Hi,

It looks like the stable branch has been updated to version 5.2.0 on
Friday (https://hg.savannah.gnu.org/hgweb/octave/rev/f4b6b170a761).

This change typically means the release is done, so is someone planning
on tagging and uploading the release to ftp?

Since the stable branch has advanced, please remember to rewind to
revision f4b6b170a761 when running 'make dist'.

Thanks,

--
mike

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

Re: uploading and tagging version 5.2.0?

siko1056
On 1/28/20 3:26 AM, Mike Miller wrote:

> Hi,
>
> It looks like the stable branch has been updated to version 5.2.0 on
> Friday (https://hg.savannah.gnu.org/hgweb/octave/rev/f4b6b170a761).
>
> This change typically means the release is done, so is someone planning
> on tagging and uploading the release to ftp?
>
> Since the stable branch has advanced, please remember to rewind to
> revision f4b6b170a761 when running 'make dist'.
>
> Thanks,
>

Yes, I did this change before to avoid Octave's typical: "We have
released but forgotten to update the date/version number in document X"

   https://hg.savannah.gnu.org/hgweb/octave/rev/c2e6725987ce

which is for example now part of our official Octave 5.1.0 tarball and
happened quite often in the pas in the heat of the release.

Personally I think we can tag any commit as 5.2.0.  There a always small
things one easily forgets.  For me a commit like

   https://hg.savannah.gnu.org/hgweb/octave/rev/5d9316571d91

is totally enough to identify a release.

Right now, I did not build the final releases to wait for urgent small
last minute commits.  I want to start the builds on Friday so we can
enjoy with beginning of February Octave 5.2.0.

Kai

Reply | Threaded
Open this post in threaded view
|

Final call for already opened bugs for Octave 5.1.90

siko1056
On 1/28/20 7:41 AM, Kai Torben Ohlhus wrote:

> On 1/28/20 3:26 AM, Mike Miller wrote:
>> Hi,
>>
>> It looks like the stable branch has been updated to version 5.2.0 on
>> Friday (https://hg.savannah.gnu.org/hgweb/octave/rev/f4b6b170a761).
>>
>> This change typically means the release is done, so is someone planning
>> on tagging and uploading the release to ftp?
>>
>> Since the stable branch has advanced, please remember to rewind to
>> revision f4b6b170a761 when running 'make dist'.
>>
>> Thanks,
>>
>
> Yes, I did this change before to avoid Octave's typical: "We have
> released but forgotten to update the date/version number in document X"
>
>    https://hg.savannah.gnu.org/hgweb/octave/rev/c2e6725987ce
>
> which is for example now part of our official Octave 5.1.0 tarball and
> happened quite often in the pas in the heat of the release.
>
> Personally I think we can tag any commit as 5.2.0.  There a always small
> things one easily forgets.  For me a commit like
>
>    https://hg.savannah.gnu.org/hgweb/octave/rev/5d9316571d91
>
> is totally enough to identify a release.
>
> Right now, I did not build the final releases to wait for urgent small
> last minute commits.  I want to start the builds on Friday so we can
> enjoy with beginning of February Octave 5.2.0.
>
> Kai
>

Dear Octave maintainers,

Friday (2020-01-31) is coming for which the 5.2.0 release is scheduled.
 Thank you for your time to test 5.1.90 and to report and fix some minor
issues so far.

Time is getting short.  Are there any issues found in 5.1.90 that need
to get fixed now?  For example [1], which seems MXE related.
Unfortunately, Savannah cannot sort by releases easily.

Please note, that (at least I) cannot accept any new issues this week,
without delaying the 5.2.0 release.

Thank you,

Kai


[1] https://savannah.gnu.org/bugs/?57673

Reply | Threaded
Open this post in threaded view
|

Re: uploading and tagging version 5.2.0?

Mike Miller-4
In reply to this post by siko1056
On Tue, Jan 28, 2020 at 07:41:31 +0900, Kai Torben Ohlhus wrote:
> Yes, I did this change before to avoid Octave's typical: "We have
> released but forgotten to update the date/version number in document X"
>
>    https://hg.savannah.gnu.org/hgweb/octave/rev/c2e6725987ce
>
> which is for example now part of our official Octave 5.1.0 tarball and
> happened quite often in the pas in the heat of the release.

Thank you, I understand. Those kinds of mistakes are indeed problems.
However, I hope we can continue to improve the release process so that
this kind of thing is no longer something to worry about.

> Personally I think we can tag any commit as 5.2.0.  There a always small
> things one easily forgets.  For me a commit like
>
>    https://hg.savannah.gnu.org/hgweb/octave/rev/5d9316571d91
>
> is totally enough to identify a release.

Well, yeah, the 'hg tag' command always creates a new commit, but it
assigns the tag to a previous revision. The commit you point isn't the
release, it created a tag for version 5.1.0 on this commit

  https://hg.savannah.gnu.org/hgweb/octave/rev/d05d6eebde10

which is exactly what I would have hoped to see for this release as
well.

Personally, I would prefer that the stable branch builds version 5.1.91
or 5.1.92 until a single commit changes the version to 5.2.0, followed
by a commit that tags it, followed by another that changes the version
to 5.2.1. This is how we decided to do it starting with version 5.1.0.

For example, this sequence of commits for version 5.1.0 updated the
version, tagged the release, and updated the version again

  https://hg.savannah.gnu.org/hgweb/octave/rev/d05d6eebde10
  https://hg.savannah.gnu.org/hgweb/octave/rev/5d9316571d91
  https://hg.savannah.gnu.org/hgweb/octave/rev/5d27954485ed

--
mike

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

Re: uploading and tagging version 5.2.0?

siko1056
On 1/29/20 4:50 AM, Mike Miller wrote:

> On Tue, Jan 28, 2020 at 07:41:31 +0900, Kai Torben Ohlhus wrote:
>> Yes, I did this change before to avoid Octave's typical: "We have
>> released but forgotten to update the date/version number in document X"
>>
>>    https://hg.savannah.gnu.org/hgweb/octave/rev/c2e6725987ce
>>
>> which is for example now part of our official Octave 5.1.0 tarball and
>> happened quite often in the pas in the heat of the release.
>
> Thank you, I understand. Those kinds of mistakes are indeed problems.
> However, I hope we can continue to improve the release process so that
> this kind of thing is no longer something to worry about.
>
>> Personally I think we can tag any commit as 5.2.0.  There a always small
>> things one easily forgets.  For me a commit like
>>
>>    https://hg.savannah.gnu.org/hgweb/octave/rev/5d9316571d91
>>
>> is totally enough to identify a release.
>
> Well, yeah, the 'hg tag' command always creates a new commit, but it
> assigns the tag to a previous revision. The commit you point isn't the
> release, it created a tag for version 5.1.0 on this commit
>
>   https://hg.savannah.gnu.org/hgweb/octave/rev/d05d6eebde10
>
> which is exactly what I would have hoped to see for this release as
> well.
>
> Personally, I would prefer that the stable branch builds version 5.1.91
> or 5.1.92 until a single commit changes the version to 5.2.0, followed
> by a commit that tags it, followed by another that changes the version
> to 5.2.1. This is how we decided to do it starting with version 5.1.0.
>
> For example, this sequence of commits for version 5.1.0 updated the
> version, tagged the release, and updated the version again
>
>   https://hg.savannah.gnu.org/hgweb/octave/rev/d05d6eebde10
>   https://hg.savannah.gnu.org/hgweb/octave/rev/5d9316571d91
>   https://hg.savannah.gnu.org/hgweb/octave/rev/5d27954485ed
>


Alright I see and agree with you.  Changing the version one week before
is too early.  I simply wanted to assure that on Jan 31st my build
system runs smoothly and I do not delay things by forgetting important
version updates =)

But for this release, is it okay, if we regard those few last days
changes as well?

Kai

Reply | Threaded
Open this post in threaded view
|

Re: uploading and tagging version 5.2.0?

Doug Stewart-4


On Tue, Jan 28, 2020 at 6:25 PM Kai Torben Ohlhus <[hidden email]> wrote:
On 1/29/20 4:50 AM, Mike Miller wrote:
> On Tue, Jan 28, 2020 at 07:41:31 +0900, Kai Torben Ohlhus wrote:
>> Yes, I did this change before to avoid Octave's typical: "We have
>> released but forgotten to update the date/version number in document X"
>>
>>    https://hg.savannah.gnu.org/hgweb/octave/rev/c2e6725987ce
>>
>> which is for example now part of our official Octave 5.1.0 tarball and
>> happened quite often in the pas in the heat of the release.
>
> Thank you, I understand. Those kinds of mistakes are indeed problems.
> However, I hope we can continue to improve the release process so that
> this kind of thing is no longer something to worry about.
>
>> Personally I think we can tag any commit as 5.2.0.  There a always small
>> things one easily forgets.  For me a commit like
>>
>>    https://hg.savannah.gnu.org/hgweb/octave/rev/5d9316571d91
>>
>> is totally enough to identify a release.
>
> Well, yeah, the 'hg tag' command always creates a new commit, but it
> assigns the tag to a previous revision. The commit you point isn't the
> release, it created a tag for version 5.1.0 on this commit
>
>   https://hg.savannah.gnu.org/hgweb/octave/rev/d05d6eebde10
>
> which is exactly what I would have hoped to see for this release as
> well.
>
> Personally, I would prefer that the stable branch builds version 5.1.91
> or 5.1.92 until a single commit changes the version to 5.2.0, followed
> by a commit that tags it, followed by another that changes the version
> to 5.2.1. This is how we decided to do it starting with version 5.1.0.
>
> For example, this sequence of commits for version 5.1.0 updated the
> version, tagged the release, and updated the version again
>
>   https://hg.savannah.gnu.org/hgweb/octave/rev/d05d6eebde10
>   https://hg.savannah.gnu.org/hgweb/octave/rev/5d9316571d91
>   https://hg.savannah.gnu.org/hgweb/octave/rev/5d27954485ed
>


Alright I see and agree with you.  Changing the version one week before
is too early.  I simply wanted to assure that on Jan 31st my build
system runs smoothly and I do not delay things by forgetting important
version updates =)

But for this release, is it okay, if we regard those few last days
changes as well?

Kai


I think it is ok this time to include these last changes. They are only related to compiling octave not to octave itself.

--
DASCertificate for 206392

Reply | Threaded
Open this post in threaded view
|

Re: uploading and tagging version 5.2.0?

John W. Eaton
Administrator
In reply to this post by Mike Miller-4
On 1/28/20 2:50 PM, Mike Miller wrote:

> which is exactly what I would have hoped to see for this release as
> well.
>
> Personally, I would prefer that the stable branch builds version 5.1.91
> or 5.1.92 until a single commit changes the version to 5.2.0, followed
> by a commit that tags it, followed by another that changes the version
> to 5.2.1. This is how we decided to do it starting with version 5.1.0.
>
> For example, this sequence of commits for version 5.1.0 updated the
> version, tagged the release, and updated the version again
>
>    https://hg.savannah.gnu.org/hgweb/octave/rev/d05d6eebde10
>    https://hg.savannah.gnu.org/hgweb/octave/rev/5d9316571d91
>    https://hg.savannah.gnu.org/hgweb/octave/rev/5d27954485ed

I agree and would also prefer to see this sequence of commits in the
mercurial archive for a releases.  But I won't worry too much about it
if the commits in the archive don't happen in exactly this sequence.
The important thing for me is that the release that is tagged in the
mercurial archive is exactly what was used to create the tar file that
is distributed from ftp.gnu.org.  We should know which revision to use
to recreate the files on ftp.gnu.org from the mercurial sources if needed.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: uploading and tagging version 5.2.0?

Mike Miller-4
In reply to this post by siko1056
On Wed, Jan 29, 2020 at 08:25:31 +0900, Kai Torben Ohlhus wrote:
> Alright I see and agree with you.  Changing the version one week before
> is too early.  I simply wanted to assure that on Jan 31st my build
> system runs smoothly and I do not delay things by forgetting important
> version updates =)
>
> But for this release, is it okay, if we regard those few last days
> changes as well?

Yeah, what's done is done, please continue with the release, and thanks
for working on it!

The next most important step is that whatever revision you tag as
"release-5-2-0" is the one that you build with "make dist" and upload
the results. So if you do "hg tag" before building the release, please
make sure to do "hg update release-5-2-0" to rewind your working tree
one commit. It's important that HG-ID stashed in octave-5.2.0.tar.xz is
exactly the revision a user will get later with "hg update
release-5-2-0".

Cheers,

--
mike

signature.asc (849 bytes) Download Attachment