[numbers] 1.0-B1 Release Proposal

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

[numbers] 1.0-B1 Release Proposal

Matt Juntunen
Hello,

I propose releasing commons-numbers 1.0-B1. I will serve as the release manager. Here are a few notes on the release:


  *   This will be a beta release. No guarantees are made for stability or compatibility with future releases.
  *   The package coordinates for the project will not be modified; they will remain as org.apache.commons.numbers.xxx as they would during a standard release.
  *   The release branch will be 1.0-B1-release.
  *   The first release candidate tag will be NUMBERS_1_0_B1_RC1. The final release tag will be NUMBERS_1_0_B1.
  *   Since this is a beta release, I propose not adding "@since" tags to the javadocs. We can add them when ready for the full 1.0 release.
  *   The ComplexUtils class will be removed from the release branch and not included in the release.

Let me know if any of the above looks incorrect. Since this is my first time as a release manager, I am sure that I will run into other issues and questions. I will reply to this email thread as needed.

Regards,
Matt J
Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

Alex Herbert

> On 29 Mar 2020, at 12:17, Matt Juntunen <[hidden email]> wrote:
>
> Hello,
>
> I propose releasing commons-numbers 1.0-B1. I will serve as the release manager. Here are a few notes on the release:
>
>
>  *   This will be a beta release. No guarantees are made for stability or compatibility with future releases.
>  *   The package coordinates for the project will not be modified; they will remain as org.apache.commons.numbers.xxx as they would during a standard release.
>  *   The release branch will be 1.0-B1-release.
>  *   The first release candidate tag will be NUMBERS_1_0_B1_RC1. The final release tag will be NUMBERS_1_0_B1.
>  *   Since this is a beta release, I propose not adding "@since" tags to the javadocs. We can add them when ready for the full 1.0 release.
>  *   The ComplexUtils class will be removed from the release branch and not included in the release.

All sounds good.

I think that you can just remove the complex-streams module from the top level pom and the dist-archive module pom. Since it is a non-destructive change (the module remains in master) I would say delete the module too so the checkout of the tag is free of this module.

>
> Let me know if any of the above looks incorrect. Since this is my first time as a release manager, I am sure that I will run into other issues and questions. I will reply to this email thread as needed.
>
> Regards,
> Matt J


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

Matt Juntunen
I made it all the way up to the vote email and then realized that the site index page does not have a link to the downloads page. So, I'm going to scrap RC1 and start RC2 either later today or tomorrow.

-Matt
________________________________
From: Alex Herbert <[hidden email]>
Sent: Sunday, March 29, 2020 9:15 AM
To: Commons Developers List <[hidden email]>
Subject: Re: [numbers] 1.0-B1 Release Proposal


> On 29 Mar 2020, at 12:17, Matt Juntunen <[hidden email]> wrote:
>
> Hello,
>
> I propose releasing commons-numbers 1.0-B1. I will serve as the release manager. Here are a few notes on the release:
>
>
>  *   This will be a beta release. No guarantees are made for stability or compatibility with future releases.
>  *   The package coordinates for the project will not be modified; they will remain as org.apache.commons.numbers.xxx as they would during a standard release.
>  *   The release branch will be 1.0-B1-release.
>  *   The first release candidate tag will be NUMBERS_1_0_B1_RC1. The final release tag will be NUMBERS_1_0_B1.
>  *   Since this is a beta release, I propose not adding "@since" tags to the javadocs. We can add them when ready for the full 1.0 release.
>  *   The ComplexUtils class will be removed from the release branch and not included in the release.

All sounds good.

I think that you can just remove the complex-streams module from the top level pom and the dist-archive module pom. Since it is a non-destructive change (the module remains in master) I would say delete the module too so the checkout of the tag is free of this module.

>
> Let me know if any of the above looks incorrect. Since this is my first time as a release manager, I am sure that I will run into other issues and questions. I will reply to this email thread as needed.
>
> Regards,
> Matt J


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

garydgregory
If "B" stands for "Beta", then make the POM version "1.0-beta1", no need
for mystery.

Gary

On Mon, Mar 30, 2020 at 9:06 AM Matt Juntunen <[hidden email]>
wrote:

> I made it all the way up to the vote email and then realized that the site
> index page does not have a link to the downloads page. So, I'm going to
> scrap RC1 and start RC2 either later today or tomorrow.
>
> -Matt
> ________________________________
> From: Alex Herbert <[hidden email]>
> Sent: Sunday, March 29, 2020 9:15 AM
> To: Commons Developers List <[hidden email]>
> Subject: Re: [numbers] 1.0-B1 Release Proposal
>
>
> > On 29 Mar 2020, at 12:17, Matt Juntunen <[hidden email]>
> wrote:
> >
> > Hello,
> >
> > I propose releasing commons-numbers 1.0-B1. I will serve as the release
> manager. Here are a few notes on the release:
> >
> >
> >  *   This will be a beta release. No guarantees are made for stability
> or compatibility with future releases.
> >  *   The package coordinates for the project will not be modified; they
> will remain as org.apache.commons.numbers.xxx as they would during a
> standard release.
> >  *   The release branch will be 1.0-B1-release.
> >  *   The first release candidate tag will be NUMBERS_1_0_B1_RC1. The
> final release tag will be NUMBERS_1_0_B1.
> >  *   Since this is a beta release, I propose not adding "@since" tags to
> the javadocs. We can add them when ready for the full 1.0 release.
> >  *   The ComplexUtils class will be removed from the release branch and
> not included in the release.
>
> All sounds good.
>
> I think that you can just remove the complex-streams module from the top
> level pom and the dist-archive module pom. Since it is a non-destructive
> change (the module remains in master) I would say delete the module too so
> the checkout of the tag is free of this module.
>
> >
> > Let me know if any of the above looks incorrect. Since this is my first
> time as a release manager, I am sure that I will run into other issues and
> questions. I will reply to this email thread as needed.
> >
> > Regards,
> > Matt J
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

Gilles Sadowski-2
In reply to this post by Matt Juntunen
Hello.

Le lun. 30 mars 2020 à 15:06, Matt Juntunen
<[hidden email]> a écrit :
>
> I made it all the way up to the vote email and then realized that the site index page does not have a link to the downloads page. So, I'm going to scrap RC1 and start RC2 either later today or tomorrow.

I'm not sure what problem you are referring to.
[Perhaps RC1 is fine (?).]

Regards,
Gilles

>
> -Matt
> ________________________________
> From: Alex Herbert <[hidden email]>
> Sent: Sunday, March 29, 2020 9:15 AM
> To: Commons Developers List <[hidden email]>
> Subject: Re: [numbers] 1.0-B1 Release Proposal
>
>
> > On 29 Mar 2020, at 12:17, Matt Juntunen <[hidden email]> wrote:
> >
> > Hello,
> >
> > I propose releasing commons-numbers 1.0-B1. I will serve as the release manager. Here are a few notes on the release:
> >
> >
> >  *   This will be a beta release. No guarantees are made for stability or compatibility with future releases.
> >  *   The package coordinates for the project will not be modified; they will remain as org.apache.commons.numbers.xxx as they would during a standard release.
> >  *   The release branch will be 1.0-B1-release.
> >  *   The first release candidate tag will be NUMBERS_1_0_B1_RC1. The final release tag will be NUMBERS_1_0_B1.
> >  *   Since this is a beta release, I propose not adding "@since" tags to the javadocs. We can add them when ready for the full 1.0 release.
> >  *   The ComplexUtils class will be removed from the release branch and not included in the release.
>
> All sounds good.
>
> I think that you can just remove the complex-streams module from the top level pom and the dist-archive module pom. Since it is a non-destructive change (the module remains in master) I would say delete the module too so the checkout of the tag is free of this module.
>
> >
> > Let me know if any of the above looks incorrect. Since this is my first time as a release manager, I am sure that I will run into other issues and questions. I will reply to this email thread as needed.
> >
> > Regards,
> > Matt J
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

Gilles Sadowski-2
Le lun. 30 mars 2020 à 15:38, Gilles Sadowski <[hidden email]> a écrit :

>
> Hello.
>
> Le lun. 30 mars 2020 à 15:06, Matt Juntunen
> <[hidden email]> a écrit :
> >
> > I made it all the way up to the vote email and then realized that the site index page does not have a link to the downloads page. So, I'm going to scrap RC1 and start RC2 either later today or tomorrow.
>
> I'm not sure what problem you are referring to.
> [Perhaps RC1 is fine (?).]

Or perhaps you should start the vote and let people collect
all issues (such as Gary's) in order to not create a new RC
for each and every improvement.

Regards,
Gilles

> >
> > -Matt
> > ________________________________
> > From: Alex Herbert <[hidden email]>
> > Sent: Sunday, March 29, 2020 9:15 AM
> > To: Commons Developers List <[hidden email]>
> > Subject: Re: [numbers] 1.0-B1 Release Proposal
> >
> >
> > > On 29 Mar 2020, at 12:17, Matt Juntunen <[hidden email]> wrote:
> > >
> > > Hello,
> > >
> > > I propose releasing commons-numbers 1.0-B1. I will serve as the release manager. Here are a few notes on the release:
> > >
> > >
> > >  *   This will be a beta release. No guarantees are made for stability or compatibility with future releases.
> > >  *   The package coordinates for the project will not be modified; they will remain as org.apache.commons.numbers.xxx as they would during a standard release.
> > >  *   The release branch will be 1.0-B1-release.
> > >  *   The first release candidate tag will be NUMBERS_1_0_B1_RC1. The final release tag will be NUMBERS_1_0_B1.
> > >  *   Since this is a beta release, I propose not adding "@since" tags to the javadocs. We can add them when ready for the full 1.0 release.
> > >  *   The ComplexUtils class will be removed from the release branch and not included in the release.
> >
> > All sounds good.
> >
> > I think that you can just remove the complex-streams module from the top level pom and the dist-archive module pom. Since it is a non-destructive change (the module remains in master) I would say delete the module too so the checkout of the tag is free of this module.
> >
> > >
> > > Let me know if any of the above looks incorrect. Since this is my first time as a release manager, I am sure that I will run into other issues and questions. I will reply to this email thread as needed.
> > >
> > > Regards,
> > > Matt J
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

Alex Herbert
In reply to this post by garydgregory

On 30/03/2020 14:27, Gary Gregory wrote:
> If "B" stands for "Beta", then make the POM version "1.0-beta1", no need
> for mystery.

In Matt's defence I think he was following the naming conventions from
the commons versioning guide [1]. That uses:

"Beta releases are denoted by adding "B<beta version number>"

I think that the explicit Beta is clearer. So should it be updated on
the versioning page to state you can use either 'B' or 'Beta' or
modified to enforce the use of "Beta<beta version number>"?

[1] https://commons.apache.org/releases/versioning.html



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

garydgregory
On Mon, Mar 30, 2020 at 9:58 AM Alex Herbert <[hidden email]>
wrote:

>
> On 30/03/2020 14:27, Gary Gregory wrote:
> > If "B" stands for "Beta", then make the POM version "1.0-beta1", no need
> > for mystery.
>
> In Matt's defence I think he was following the naming conventions from
> the commons versioning guide [1]. That uses:
>
> "Beta releases are denoted by adding "B<beta version number>"
>
> I think that the explicit Beta is clearer. So should it be updated on
> the versioning page to state you can use either 'B' or 'Beta' or
> modified to enforce the use of "Beta<beta version number>"?
>

Most people know what a 'beta' version is, but 'B' is too cryptic IMO. I'll
pool the ML.

Gary


>
> [1] https://commons.apache.org/releases/versioning.html
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

Rob Tompkins


> On Mar 30, 2020, at 10:11 AM, Gary Gregory <[hidden email]> wrote:
>
> On Mon, Mar 30, 2020 at 9:58 AM Alex Herbert <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>>
>> On 30/03/2020 14:27, Gary Gregory wrote:
>>> If "B" stands for "Beta", then make the POM version "1.0-beta1", no need
>>> for mystery.
>>
>> In Matt's defence I think he was following the naming conventions from
>> the commons versioning guide [1]. That uses:
>>
>> "Beta releases are denoted by adding "B<beta version number>"
>>
>> I think that the explicit Beta is clearer. So should it be updated on
>> the versioning page to state you can use either 'B' or 'Beta' or
>> modified to enforce the use of "Beta<beta version number>"?
>>
>
> Most people know what a 'beta' version is, but 'B' is too cryptic IMO. I'll
> pool the ML.

B1 was clear to me, but I agree that more specificity is always better.

-Rob

>
> Gary
>
>
>>
>> [1] https://commons.apache.org/releases/versioning.html <https://commons.apache.org/releases/versioning.html>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

Matt Juntunen
The issue I saw with the site [1] was that the text under the Releases section says "There is no offcial release yet. Come and join development work!" Clearly, that won't work for a release version.

Also, the Nexus staging repository (1496) failed validation because it could not find my key in a public key server. I thought I had added it but apparently it didn't work.

-Matt

[1] https://home.apache.org/~mattjuntunen/commons-numbers-1.0-B1-RC1-site/
________________________________
From: Rob Tompkins <[hidden email]>
Sent: Monday, March 30, 2020 10:13 AM
To: Commons Developers List <[hidden email]>
Subject: Re: [numbers] 1.0-B1 Release Proposal



> On Mar 30, 2020, at 10:11 AM, Gary Gregory <[hidden email]> wrote:
>
> On Mon, Mar 30, 2020 at 9:58 AM Alex Herbert <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>>
>> On 30/03/2020 14:27, Gary Gregory wrote:
>>> If "B" stands for "Beta", then make the POM version "1.0-beta1", no need
>>> for mystery.
>>
>> In Matt's defence I think he was following the naming conventions from
>> the commons versioning guide [1]. That uses:
>>
>> "Beta releases are denoted by adding "B<beta version number>"
>>
>> I think that the explicit Beta is clearer. So should it be updated on
>> the versioning page to state you can use either 'B' or 'Beta' or
>> modified to enforce the use of "Beta<beta version number>"?
>>
>
> Most people know what a 'beta' version is, but 'B' is too cryptic IMO. I'll
> pool the ML.

B1 was clear to me, but I agree that more specificity is always better.

-Rob

>
> Gary
>
>
>>
>> [1] https://commons.apache.org/releases/versioning.html <https://commons.apache.org/releases/versioning.html>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

Rob Tompkins
That seems reasonable to me.

> On Mar 30, 2020, at 10:19 AM, Matt Juntunen <[hidden email]> wrote:
>
> The issue I saw with the site [1] was that the text under the Releases section says "There is no offcial release yet. Come and join development work!" Clearly, that won't work for a release version.
>
> Also, the Nexus staging repository (1496) failed validation because it could not find my key in a public key server. I thought I had added it but apparently it didn't work.
>
> -Matt
>
> [1] https://home.apache.org/~mattjuntunen/commons-numbers-1.0-B1-RC1-site/
> ________________________________
> From: Rob Tompkins <[hidden email]>
> Sent: Monday, March 30, 2020 10:13 AM
> To: Commons Developers List <[hidden email]>
> Subject: Re: [numbers] 1.0-B1 Release Proposal
>
>
>
>> On Mar 30, 2020, at 10:11 AM, Gary Gregory <[hidden email]> wrote:
>>
>> On Mon, Mar 30, 2020 at 9:58 AM Alex Herbert <[hidden email] <mailto:[hidden email]>>
>> wrote:
>>
>>>
>>> On 30/03/2020 14:27, Gary Gregory wrote:
>>>> If "B" stands for "Beta", then make the POM version "1.0-beta1", no need
>>>> for mystery.
>>>
>>> In Matt's defence I think he was following the naming conventions from
>>> the commons versioning guide [1]. That uses:
>>>
>>> "Beta releases are denoted by adding "B<beta version number>"
>>>
>>> I think that the explicit Beta is clearer. So should it be updated on
>>> the versioning page to state you can use either 'B' or 'Beta' or
>>> modified to enforce the use of "Beta<beta version number>"?
>>>
>>
>> Most people know what a 'beta' version is, but 'B' is too cryptic IMO. I'll
>> pool the ML.
>
> B1 was clear to me, but I agree that more specificity is always better.
>
> -Rob
>
>>
>> Gary
>>
>>
>>>
>>> [1] https://commons.apache.org/releases/versioning.html <https://commons.apache.org/releases/versioning.html>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
>>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

Gilles Sadowski-2
In reply to this post by Matt Juntunen
Hi.

Le lun. 30 mars 2020 à 16:19, Matt Juntunen
<[hidden email]> a écrit :
>
> The issue I saw with the site [1] was that the text under the Releases section says "There is no offcial release yet. Come and join development work!" Clearly, that won't work for a release version.

Ah OK.  I had created that contents to avoid misunderstandings as the
usual download
page would point non-existing artefacts.
IIRC, regenerating the download page should fix this.

> Also, the Nexus staging repository (1496) failed validation because it could not find my key in a public key server. I thought I had added it but apparently it didn't work.

Never encountered this issue...
Did you register your key at
   https://id.apache.org/
?

Regards,
Gilles

> > [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

Gilles Sadowski-2
Le lun. 30 mars 2020 à 17:27, Gilles Sadowski <[hidden email]> a écrit :

>
> Hi.
>
> Le lun. 30 mars 2020 à 16:19, Matt Juntunen
> <[hidden email]> a écrit :
> >
> > The issue I saw with the site [1] was that the text under the Releases section says "There is no offcial release yet. Come and join development work!" Clearly, that won't work for a release version.
>
> Ah OK.  I had created that contents to avoid misunderstandings as the
> usual download
> page would point non-existing artefacts.
> IIRC, regenerating the download page should fix this.
>
> > Also, the Nexus staging repository (1496) failed validation because it could not find my key in a public key server. I thought I had added it but apparently it didn't work.
>
> Never encountered this issue...
> Did you register your key at
>    https://id.apache.org/
> ?

Sorry; that shouldn't be the problem since I also did not
mention a GPG key there. :-}

Regards,
Gilles

> > > [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

Alex Herbert

On 30/03/2020 16:30, Gilles Sadowski wrote:

> Le lun. 30 mars 2020 à 17:27, Gilles Sadowski <[hidden email]> a écrit :
>> Hi.
>>
>> Le lun. 30 mars 2020 à 16:19, Matt Juntunen
>> <[hidden email]> a écrit :
>>> The issue I saw with the site [1] was that the text under the Releases section says "There is no offcial release yet. Come and join development work!" Clearly, that won't work for a release version.
>> Ah OK.  I had created that contents to avoid misunderstandings as the
>> usual download
>> page would point non-existing artefacts.
>> IIRC, regenerating the download page should fix this.
>>
>>> Also, the Nexus staging repository (1496) failed validation because it could not find my key in a public key server. I thought I had added it but apparently it didn't work.
>> Never encountered this issue...
>> Did you register your key at
>>     https://id.apache.org/
>> ?
> Sorry; that shouldn't be the problem since I also did not
> mention a GPG key there. :-}
>
> Regards,
> Gilles

You also have to push your key to a public keyserver (e.g. [1]) as
stated in the release signing guide [2], e.g.

 > gpg --send-key XYZ....

 > gpg --keyserver pgp.key-server.io --search-keys [hidden email]

... this should find Gilles

 > gpg --keyserver pgp.key-server.io --search-keys [hidden email]

... nothing

If you already did this then it may take a few hours for the key to
replicate around all the various public key servers.

[1] https://pgp.key-server.io/

[2] http://www.apache.org/dev/release-signing.html#keyserver-upload

>
>>>> [...]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

sebb-2-2
On Mon, 30 Mar 2020 at 17:24, Alex Herbert <[hidden email]> wrote:

>
>
> On 30/03/2020 16:30, Gilles Sadowski wrote:
> > Le lun. 30 mars 2020 à 17:27, Gilles Sadowski <[hidden email]> a écrit :
> >> Hi.
> >>
> >> Le lun. 30 mars 2020 à 16:19, Matt Juntunen
> >> <[hidden email]> a écrit :
> >>> The issue I saw with the site [1] was that the text under the Releases section says "There is no offcial release yet. Come and join development work!" Clearly, that won't work for a release version.
> >> Ah OK.  I had created that contents to avoid misunderstandings as the
> >> usual download
> >> page would point non-existing artefacts.
> >> IIRC, regenerating the download page should fix this.
> >>
> >>> Also, the Nexus staging repository (1496) failed validation because it could not find my key in a public key server. I thought I had added it but apparently it didn't work.
> >> Never encountered this issue...
> >> Did you register your key at
> >>     https://id.apache.org/
> >> ?
> > Sorry; that shouldn't be the problem since I also did not
> > mention a GPG key there. :-}
> >
> > Regards,
> > Gilles
>
> You also have to push your key to a public keyserver (e.g. [1]) as
> stated in the release signing guide [2], e.g.
>
>  > gpg --send-key XYZ....
>
>  > gpg --keyserver pgp.key-server.io --search-keys [hidden email]
>
> ... this should find Gilles
>
>  > gpg --keyserver pgp.key-server.io --search-keys [hidden email]
>
> ... nothing
>
> If you already did this then it may take a few hours for the key to
> replicate around all the various public key servers.
>

Note that there seem to be some issues with propagation of keys
between key servers recently.
It may take days, and/or you may need to upload to a different server.

> [1] https://pgp.key-server.io/
>
> [2] http://www.apache.org/dev/release-signing.html#keyserver-upload
>
> >
> >>>> [...]
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

Matt Juntunen
Thanks. I think I have the gpg key sorted now.

I can probably start on RC2 tomorrow. It sounds like we've agreed to go with "1.0-beta1" for the release version so I'm wondering what to do with the existing release branch (1.0-B1-release) and tag (NUMBERS_1_0_B1_RC1). These should have probably been 1.0-beta1-release and NUMBERS_1_0_BETA1_RC1. Is it possible to drop those and recreate them or would it be better to leave the current branch and tag names as-is and use the NUMBER_1_0_BETA1_RCX tag pattern going forward?

-Matt
________________________________
From: sebb <[hidden email]>
Sent: Monday, March 30, 2020 12:25 PM
To: Commons Developers List <[hidden email]>
Subject: Re: [numbers] 1.0-B1 Release Proposal

On Mon, 30 Mar 2020 at 17:24, Alex Herbert <[hidden email]> wrote:

>
>
> On 30/03/2020 16:30, Gilles Sadowski wrote:
> > Le lun. 30 mars 2020 à 17:27, Gilles Sadowski <[hidden email]> a écrit :
> >> Hi.
> >>
> >> Le lun. 30 mars 2020 à 16:19, Matt Juntunen
> >> <[hidden email]> a écrit :
> >>> The issue I saw with the site [1] was that the text under the Releases section says "There is no offcial release yet. Come and join development work!" Clearly, that won't work for a release version.
> >> Ah OK.  I had created that contents to avoid misunderstandings as the
> >> usual download
> >> page would point non-existing artefacts.
> >> IIRC, regenerating the download page should fix this.
> >>
> >>> Also, the Nexus staging repository (1496) failed validation because it could not find my key in a public key server. I thought I had added it but apparently it didn't work.
> >> Never encountered this issue...
> >> Did you register your key at
> >>     https://id.apache.org/
> >> ?
> > Sorry; that shouldn't be the problem since I also did not
> > mention a GPG key there. :-}
> >
> > Regards,
> > Gilles
>
> You also have to push your key to a public keyserver (e.g. [1]) as
> stated in the release signing guide [2], e.g.
>
>  > gpg --send-key XYZ....
>
>  > gpg --keyserver pgp.key-server.io --search-keys [hidden email]
>
> ... this should find Gilles
>
>  > gpg --keyserver pgp.key-server.io --search-keys [hidden email]
>
> ... nothing
>
> If you already did this then it may take a few hours for the key to
> replicate around all the various public key servers.
>

Note that there seem to be some issues with propagation of keys
between key servers recently.
It may take days, and/or you may need to upload to a different server.

> [1] https://pgp.key-server.io/
>
> [2] http://www.apache.org/dev/release-signing.html#keyserver-upload
>
> >
> >>>> [...]
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

Gilles Sadowski-2
Hi.

Le lun. 30 mars 2020 à 23:37, Matt Juntunen
<[hidden email]> a écrit :
>
> Thanks. I think I have the gpg key sorted now.
>
> I can probably start on RC2 tomorrow. It sounds like we've agreed to go with "1.0-beta1" for the release version so I'm wondering what to do with the existing release branch (1.0-B1-release) and tag (NUMBERS_1_0_B1_RC1). These should have probably been 1.0-beta1-release and NUMBERS_1_0_BETA1_RC1. Is it possible to drop those and recreate them or would it be better to leave the current branch and tag names as-is and use the NUMBER_1_0_BETA1_RCX tag pattern going forward?

IMHO, no harm done by removing.
Can someone confirm?

Regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

sebb-2-2
On Mon, 30 Mar 2020 at 23:20, Gilles Sadowski <[hidden email]> wrote:

>
> Hi.
>
> Le lun. 30 mars 2020 à 23:37, Matt Juntunen
> <[hidden email]> a écrit :
> >
> > Thanks. I think I have the gpg key sorted now.
> >
> > I can probably start on RC2 tomorrow. It sounds like we've agreed to go with "1.0-beta1" for the release version so I'm wondering what to do with the existing release branch (1.0-B1-release) and tag (NUMBERS_1_0_B1_RC1). These should have probably been 1.0-beta1-release and NUMBERS_1_0_BETA1_RC1. Is it possible to drop those and recreate them or would it be better to leave the current branch and tag names as-is and use the NUMBER_1_0_BETA1_RCX tag pattern going forward?
>
> IMHO, no harm done by removing.

Equally, what's the harm in leaving them?

I would leave well alone for now at least.
Can always delete the tag later if necessary.

> Can someone confirm?
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

Gilles Sadowski-2
Le mar. 31 mars 2020 à 14:11, sebb <[hidden email]> a écrit :

>
> On Mon, 30 Mar 2020 at 23:20, Gilles Sadowski <[hidden email]> wrote:
> >
> > Hi.
> >
> > Le lun. 30 mars 2020 à 23:37, Matt Juntunen
> > <[hidden email]> a écrit :
> > >
> > > Thanks. I think I have the gpg key sorted now.
> > >
> > > I can probably start on RC2 tomorrow. It sounds like we've agreed to go with "1.0-beta1" for the release version so I'm wondering what to do with the existing release branch (1.0-B1-release) and tag (NUMBERS_1_0_B1_RC1). These should have probably been 1.0-beta1-release and NUMBERS_1_0_BETA1_RC1. Is it possible to drop those and recreate them or would it be better to leave the current branch and tag names as-is and use the NUMBER_1_0_BETA1_RCX tag pattern going forward?
> >
> > IMHO, no harm done by removing.
>
> Equally, what's the harm in leaving them?
>
> I would leave well alone for now at least.
> Can always delete the tag later if necessary.

I prefer cleaning up while we know that it doesn't do any harm;
later, it's pretty certain that we'll wonder why it's there, and in
doubt, we probably will not delete anything.

My understanding of the original question was whether it is
going to cause technical trouble.

> > Can someone confirm?

And my question above was indirectly referring to the once
upon a time mentioned that no branch could ever be deleted...


Regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] 1.0-B1 Release Proposal

garydgregory
On Tue, Mar 31, 2020 at 8:27 AM Gilles Sadowski <[hidden email]>
wrote:

> Le mar. 31 mars 2020 à 14:11, sebb <[hidden email]> a écrit :
> >
> > On Mon, 30 Mar 2020 at 23:20, Gilles Sadowski <[hidden email]>
> wrote:
> > >
> > > Hi.
> > >
> > > Le lun. 30 mars 2020 à 23:37, Matt Juntunen
> > > <[hidden email]> a écrit :
> > > >
> > > > Thanks. I think I have the gpg key sorted now.
> > > >
> > > > I can probably start on RC2 tomorrow. It sounds like we've agreed to
> go with "1.0-beta1" for the release version so I'm wondering what to do
> with the existing release branch (1.0-B1-release) and tag
> (NUMBERS_1_0_B1_RC1). These should have probably been 1.0-beta1-release and
> NUMBERS_1_0_BETA1_RC1. Is it possible to drop those and recreate them or
> would it be better to leave the current branch and tag names as-is and use
> the NUMBER_1_0_BETA1_RCX tag pattern going forward?
>

IMO, the tagging should be:

<component-id>-<release>[-RC#]

So:

commons-number-1.0-beta1-RC1
commons-number-1.0-beta1

At least that's what I've been doing on all the release I RM.

Gary

 > >

> > > IMHO, no harm done by removing.
> >
> > Equally, what's the harm in leaving them?
> >
> > I would leave well alone for now at least.
> > Can always delete the tag later if necessary.
>
> I prefer cleaning up while we know that it doesn't do any harm;
> later, it's pretty certain that we'll wonder why it's there, and in
> doubt, we probably will not delete anything.
>
> My understanding of the original question was whether it is
> going to cause technical trouble.
>
> > > Can someone confirm?
>
> And my question above was indirectly referring to the once
> upon a time mentioned that no branch could ever be deleted...
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
12