[Vote] Format of "git" tags

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

[Vote] Format of "git" tags

Gilles Sadowski-2
Hello.

This vote is a follow-up of the discussion that started in
another thread.[1]

As one of the many small steps towards convergence of
the release processes for all Commons components, it is
proposed that the same format be used when creating "git"
tags.[2]

As Gary noted (in the referred thread), the tag is namely used
when cloning a release candidate.[3]

Alternatives (using the yet-to-be-created tag for the release
candidate of the first beta version of [Numbers] as an example):

 [ ] Option 1: NUMBERS_1_0_BETA1_RC1
 [ ] Option 2: commons-numbers-1.0-beta1-rc1
 [ ] Option 3: commons-numbers_v1.0-beta1_rc1

Please give your choice of the format that should be used from
now on.

Thanks,
Gilles

[1] https://markmail.org/message/n457skstbxbirvhp
[2] https://git-scm.com/book/en/v2/Git-Basics-Tagging
[3] https://git-scm.com/docs/git-clone

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

Reply | Threaded
Open this post in threaded view
|

Re: [Vote] Format of "git" tags

Rob Tompkins
Option 2 - +1

> On Apr 1, 2020, at 7:02 AM, Gilles Sadowski <[hidden email]> wrote:
>
> Hello.
>
> This vote is a follow-up of the discussion that started in
> another thread.[1]
>
> As one of the many small steps towards convergence of
> the release processes for all Commons components, it is
> proposed that the same format be used when creating "git"
> tags.[2]
>
> As Gary noted (in the referred thread), the tag is namely used
> when cloning a release candidate.[3]
>
> Alternatives (using the yet-to-be-created tag for the release
> candidate of the first beta version of [Numbers] as an example):
>
> [ ] Option 1: NUMBERS_1_0_BETA1_RC1
> [ ] Option 2: commons-numbers-1.0-beta1-rc1
> [ ] Option 3: commons-numbers_v1.0-beta1_rc1
>
> Please give your choice of the format that should be used from
> now on.
>
> Thanks,
> Gilles
>
> [1] https://markmail.org/message/n457skstbxbirvhp
> [2] https://git-scm.com/book/en/v2/Git-Basics-Tagging
> [3] https://git-scm.com/docs/git-clone
>
> ---------------------------------------------------------------------
> 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: [Vote] Format of "git" tags

Matt Juntunen
+1 for option 2 (commons-numbers-1.0-beta1-rc1)

-Matt
________________________________
From: Rob Tompkins <[hidden email]>
Sent: Wednesday, April 1, 2020 7:07 AM
To: Commons Developers List <[hidden email]>
Subject: Re: [Vote] Format of "git" tags

Option 2 - +1

> On Apr 1, 2020, at 7:02 AM, Gilles Sadowski <[hidden email]> wrote:
>
> Hello.
>
> This vote is a follow-up of the discussion that started in
> another thread.[1]
>
> As one of the many small steps towards convergence of
> the release processes for all Commons components, it is
> proposed that the same format be used when creating "git"
> tags.[2]
>
> As Gary noted (in the referred thread), the tag is namely used
> when cloning a release candidate.[3]
>
> Alternatives (using the yet-to-be-created tag for the release
> candidate of the first beta version of [Numbers] as an example):
>
> [ ] Option 1: NUMBERS_1_0_BETA1_RC1
> [ ] Option 2: commons-numbers-1.0-beta1-rc1
> [ ] Option 3: commons-numbers_v1.0-beta1_rc1
>
> Please give your choice of the format that should be used from
> now on.
>
> Thanks,
> Gilles
>
> [1] https://markmail.org/message/n457skstbxbirvhp
> [2] https://git-scm.com/book/en/v2/Git-Basics-Tagging
> [3] https://git-scm.com/docs/git-clone
>
> ---------------------------------------------------------------------
> 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: [Vote] Format of "git" tags

Stefan Bodewig
In reply to this post by Gilles Sadowski-2
On 2020-04-01, Gilles Sadowski wrote:

> Alternatives (using the yet-to-be-created tag for the release
> candidate of the first beta version of [Numbers] as an example):

>  [ ] Option 1: NUMBERS_1_0_BETA1_RC1
>  [ ] Option 2: commons-numbers-1.0-beta1-rc1
>  [ ] Option 3: commons-numbers_v1.0-beta1_rc1

+0 to each of them as long as
http://commons.apache.org/releases/prepare.html gets updated with the
outcome.

Stefan

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

Reply | Threaded
Open this post in threaded view
|

Re: [Vote] Format of "git" tags

garydgregory
In reply to this post by Gilles Sadowski-2
Option 2 +1

The docs should also make sure that release tags are in the form rel/...
which makes them read-only.

Do you plan on renaming existing tags?

Gary

On Wed, Apr 1, 2020, 07:02 Gilles Sadowski <[hidden email]> wrote:

> Hello.
>
> This vote is a follow-up of the discussion that started in
> another thread.[1]
>
> As one of the many small steps towards convergence of
> the release processes for all Commons components, it is
> proposed that the same format be used when creating "git"
> tags.[2]
>
> As Gary noted (in the referred thread), the tag is namely used
> when cloning a release candidate.[3]
>
> Alternatives (using the yet-to-be-created tag for the release
> candidate of the first beta version of [Numbers] as an example):
>
>  [ ] Option 1: NUMBERS_1_0_BETA1_RC1
>  [ ] Option 2: commons-numbers-1.0-beta1-rc1
>  [ ] Option 3: commons-numbers_v1.0-beta1_rc1
>
> Please give your choice of the format that should be used from
> now on.
>
> Thanks,
> Gilles
>
> [1] https://markmail.org/message/n457skstbxbirvhp
> [2] https://git-scm.com/book/en/v2/Git-Basics-Tagging
> [3] https://git-scm.com/docs/git-clone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Vote] Format of "git" tags

Gilles Sadowski-2
Hello.

Le mer. 1 avr. 2020 à 13:42, Gary Gregory <[hidden email]> a écrit :
>
> Option 2 +1
>
> The docs should also make sure that release tags are in the form rel/...
> which makes them read-only.

Yes, we should certainly update the various howtos.
Could you post a link to where this policy is defined?

> Do you plan on renaming existing tags?

At first sight, that does not seem wise: It will make many
vote threads contain dangling references.


Gilles

>
> Gary
>
> On Wed, Apr 1, 2020, 07:02 Gilles Sadowski <[hidden email]> wrote:
>
> > Hello.
> >
> > This vote is a follow-up of the discussion that started in
> > another thread.[1]
> >
> > As one of the many small steps towards convergence of
> > the release processes for all Commons components, it is
> > proposed that the same format be used when creating "git"
> > tags.[2]
> >
> > As Gary noted (in the referred thread), the tag is namely used
> > when cloning a release candidate.[3]
> >
> > Alternatives (using the yet-to-be-created tag for the release
> > candidate of the first beta version of [Numbers] as an example):
> >
> >  [ ] Option 1: NUMBERS_1_0_BETA1_RC1
> >  [ ] Option 2: commons-numbers-1.0-beta1-rc1
> >  [ ] Option 3: commons-numbers_v1.0-beta1_rc1
> >
> > Please give your choice of the format that should be used from
> > now on.
> >
> > Thanks,
> > Gilles
> >
> > [1] https://markmail.org/message/n457skstbxbirvhp
> > [2] https://git-scm.com/book/en/v2/Git-Basics-Tagging
> > [3] https://git-scm.com/docs/git-clone

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

Reply | Threaded
Open this post in threaded view
|

Re: [Vote] Format of "git" tags

Bruno P. Kinoshita-3
In reply to this post by Gilles Sadowski-2
+1 option 2

Sent from Yahoo Mail on Android
 
  On Thu, 2 Apr 2020 at 0:02, Gilles Sadowski<[hidden email]> wrote:   Hello.

This vote is a follow-up of the discussion that started in
another thread.[1]

As one of the many small steps towards convergence of
the release processes for all Commons components, it is
proposed that the same format be used when creating "git"
tags.[2]

As Gary noted (in the referred thread), the tag is namely used
when cloning a release candidate.[3]

Alternatives (using the yet-to-be-created tag for the release
candidate of the first beta version of [Numbers] as an example):

 [ ] Option 1: NUMBERS_1_0_BETA1_RC1
 [ ] Option 2: commons-numbers-1.0-beta1-rc1
 [ ] Option 3: commons-numbers_v1.0-beta1_rc1

Please give your choice of the format that should be used from
now on.

Thanks,
Gilles

[1] https://markmail.org/message/n457skstbxbirvhp
[2] https://git-scm.com/book/en/v2/Git-Basics-Tagging
[3] https://git-scm.com/docs/git-clone

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

 
Reply | Threaded
Open this post in threaded view
|

Re: [Vote] Format of "git" tags

Stefan Bodewig
In reply to this post by garydgregory
On 2020-04-01, Gary Gregory wrote:

> The docs should also make sure that release tags are in the form rel/...
> which makes them read-only.

So far I've created a new tag under rel/ for the RC tag when the vote
has been accepted. So only "real" releases end up there.

If we want to create all our tags there, things may look a bit
confusing. But I could live with that as well.

Stefan

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

Reply | Threaded
Open this post in threaded view
|

Re: [Vote] Format of "git" tags

Rob Tompkins


> On Apr 1, 2020, at 8:22 AM, Stefan Bodewig <[hidden email]> wrote:
>
> On 2020-04-01, Gary Gregory wrote:
>
>> The docs should also make sure that release tags are in the form rel/...
>> which makes them read-only.
>
> So far I've created a new tag under rel/ for the RC tag when the vote
> has been accepted. So only "real" releases end up there.
>
> If we want to create all our tags there, things may look a bit
> confusing. But I could live with that as well.

I would think we would only want to put tags that have a [VOTE] thread associated under rel/ because they are required to remain in the public domain. I have, at times, found the need to delete a tag due to mistakes on my part. But, I’ve only done so if there has been no email [VOTE]. If there was an email [VOTE] in existence, then my move has been to increment the RC version.

My 2 cents,
-Rob

>
> Stefan
>
> ---------------------------------------------------------------------
> 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: [Vote] Format of "git" tags

Gilles Sadowski-2
Le mer. 1 avr. 2020 à 14:33, Rob Tompkins <[hidden email]> a écrit :

>
>
>
> > On Apr 1, 2020, at 8:22 AM, Stefan Bodewig <[hidden email]> wrote:
> >
> > On 2020-04-01, Gary Gregory wrote:
> >
> >> The docs should also make sure that release tags are in the form rel/...
> >> which makes them read-only.
> >
> > So far I've created a new tag under rel/ for the RC tag when the vote
> > has been accepted. So only "real" releases end up there.
> >
> > If we want to create all our tags there, things may look a bit
> > confusing. But I could live with that as well.
>
> I would think we would only want to put tags that have a [VOTE] thread associated under rel/ because they are required to remain in the public domain.

A vote that *passed*, you mean (?).
Everything that is not officially released is so-to-speak "internal".
Is there any interest in having failed attempts made read-only?

The "history" is kept through the ML archives (the "[Vote]" thread
and its corresponding tag/commit).

Gilles

> I have, at times, found the need to delete a tag due to mistakes on my part. But, I’ve only done so if there has been no email [VOTE]. If there was an email [VOTE] in existence, then my move has been to increment the RC version.
>
> My 2 cents,
> -Rob
>
> >
> > Stefan

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

Reply | Threaded
Open this post in threaded view
|

Re: [Vote] Format of "git" tags

Rob Tompkins


> On Apr 1, 2020, at 8:43 AM, Gilles Sadowski <[hidden email]> wrote:
>
> Le mer. 1 avr. 2020 à 14:33, Rob Tompkins <[hidden email] <mailto:[hidden email]>> a écrit :
>>
>>
>>
>>> On Apr 1, 2020, at 8:22 AM, Stefan Bodewig <[hidden email]> wrote:
>>>
>>> On 2020-04-01, Gary Gregory wrote:
>>>
>>>> The docs should also make sure that release tags are in the form rel/...
>>>> which makes them read-only.
>>>
>>> So far I've created a new tag under rel/ for the RC tag when the vote
>>> has been accepted. So only "real" releases end up there.
>>>
>>> If we want to create all our tags there, things may look a bit
>>> confusing. But I could live with that as well.
>>
>> I would think we would only want to put tags that have a [VOTE] thread associated under rel/ because they are required to remain in the public domain.
>
> A vote that *passed*, you mean (?).
> Everything that is not officially released is so-to-speak "internal".
> Is there any interest in having failed attempts made read-only?
>

Yes, I would think we would want the code on which we voted kept as well as the emails. I agree the commits are kept in the [VOTE] thread, but those are technically mutable. If I understand correctly, [infra] has put a special restriction on our mirrors of GitHub such that tags with the prefix “rel/“ cannot be overwritten. Thus, the only way to ensure the history is permanently retained is to have it be under a tag with a “rel/“ prefix. We otherwise rely on the good will (which I do trust) of our committers to not force push over a branch or delete RC tags.

-Rob

> The "history" is kept through the ML archives (the "[Vote]" thread
> and its corresponding tag/commit).
>
> Gilles
>
>> I have, at times, found the need to delete a tag due to mistakes on my part. But, I’ve only done so if there has been no email [VOTE]. If there was an email [VOTE] in existence, then my move has been to increment the RC version.
>>
>> My 2 cents,
>> -Rob
>>
>>>
>>> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Vote] Format of "git" tags

Gilles Sadowski-2
> > On Apr 1, 2020, at 8:43 AM, Gilles Sadowski <[hidden email]> wrote:
> >
> > Le mer. 1 avr. 2020 à 14:33, Rob Tompkins <[hidden email] <mailto:[hidden email]>> a écrit :
> >>
> >>
> >>
> >>> On Apr 1, 2020, at 8:22 AM, Stefan Bodewig <[hidden email]> wrote:
> >>>
> >>> On 2020-04-01, Gary Gregory wrote:
> >>>
> >>>> The docs should also make sure that release tags are in the form rel/...
> >>>> which makes them read-only.
> >>>
> >>> So far I've created a new tag under rel/ for the RC tag when the vote
> >>> has been accepted. So only "real" releases end up there.
> >>>
> >>> If we want to create all our tags there, things may look a bit
> >>> confusing. But I could live with that as well.
> >>
> >> I would think we would only want to put tags that have a [VOTE] thread associated under rel/ because they are required to remain in the public domain.
> >
> > A vote that *passed*, you mean (?).
> > Everything that is not officially released is so-to-speak "internal".
> > Is there any interest in having failed attempts made read-only?
> >
>
> Yes, I would think we would want the code on which we voted kept as well as the emails. I agree the commits are kept in the [VOTE] thread, but those are technically mutable. If I understand correctly, [infra] has put a special restriction on our mirrors of GitHub such that tags with the prefix “rel/“ cannot be overwritten. Thus, the only way to ensure the history is permanently retained is to have it be under a tag with a “rel/“ prefix. We otherwise rely on the good will (which I do trust) of our committers to not force push over a branch or delete RC tags.

I think I understand the purpose of "rel/".  My take is that it is
*not* useful to have a tag history.  [IIUC "rel/" is for "release",
not release history.]

The code history is in the commits; the release history is in the
*one* tag that has been accepted for release (and must be
archived with the "rel/" prefix).

Even if other "rc" tags were deleted, what would be the real
harm?  The commit associated with the tag (also mentioned in
the "[Vote]" message) would still exist.

To confirm, one way or the other, could someone please post
the link to where this was all explained?

Thanks,
Gilles

> -Rob
>
> > The "history" is kept through the ML archives (the "[Vote]" thread
> > and its corresponding tag/commit).
> >
> > Gilles
> >
> >> I have, at times, found the need to delete a tag due to mistakes on my part. But, I’ve only done so if there has been no email [VOTE]. If there was an email [VOTE] in existence, then my move has been to increment the RC version.
> >>
> >> My 2 cents,
> >> -Rob
> >>
> >>>
> >>> Stefan

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

Reply | Threaded
Open this post in threaded view
|

Re: [Vote] Format of "git" tags

sebb-2-2
On Wed, 1 Apr 2020 at 14:24, Gilles Sadowski <[hidden email]> wrote:

>
> > > On Apr 1, 2020, at 8:43 AM, Gilles Sadowski <[hidden email]> wrote:
> > >
> > > Le mer. 1 avr. 2020 à 14:33, Rob Tompkins <[hidden email] <mailto:[hidden email]>> a écrit :
> > >>
> > >>
> > >>
> > >>> On Apr 1, 2020, at 8:22 AM, Stefan Bodewig <[hidden email]> wrote:
> > >>>
> > >>> On 2020-04-01, Gary Gregory wrote:
> > >>>
> > >>>> The docs should also make sure that release tags are in the form rel/...
> > >>>> which makes them read-only.
> > >>>
> > >>> So far I've created a new tag under rel/ for the RC tag when the vote
> > >>> has been accepted. So only "real" releases end up there.
> > >>>
> > >>> If we want to create all our tags there, things may look a bit
> > >>> confusing. But I could live with that as well.
> > >>
> > >> I would think we would only want to put tags that have a [VOTE] thread associated under rel/ because they are required to remain in the public domain.
> > >
> > > A vote that *passed*, you mean (?).
> > > Everything that is not officially released is so-to-speak "internal".
> > > Is there any interest in having failed attempts made read-only?
> > >
> >
> > Yes, I would think we would want the code on which we voted kept as well as the emails. I agree the commits are kept in the [VOTE] thread, but those are technically mutable. If I understand correctly, [infra] has put a special restriction on our mirrors of GitHub such that tags with the prefix “rel/“ cannot be overwritten. Thus, the only way to ensure the history is permanently retained is to have it be under a tag with a “rel/“ prefix. We otherwise rely on the good will (which I do trust) of our committers to not force push over a branch or delete RC tags.
>
> I think I understand the purpose of "rel/".  My take is that it is
> *not* useful to have a tag history.  [IIUC "rel/" is for "release",
> not release history.]

+1

> The code history is in the commits; the release history is in the
> *one* tag that has been accepted for release (and must be
> archived with the "rel/" prefix).
>
> Even if other "rc" tags were deleted, what would be the real
> harm?  The commit associated with the tag (also mentioned in
> the "[Vote]" message) would still exist.

That is the most important apect.
Provided that the rel/tag references the commit, then the commit will
not be lost.

The VOTE emails could reference the release tag that will be created
if the vote passes.

> To confirm, one way or the other, could someone please post
> the link to where this was all explained?
>
> Thanks,
> Gilles
>
> > -Rob
> >
> > > The "history" is kept through the ML archives (the "[Vote]" thread
> > > and its corresponding tag/commit).
> > >
> > > Gilles
> > >
> > >> I have, at times, found the need to delete a tag due to mistakes on my part. But, I’ve only done so if there has been no email [VOTE]. If there was an email [VOTE] in existence, then my move has been to increment the RC version.
> > >>
> > >> My 2 cents,
> > >> -Rob
> > >>
> > >>>
> > >>> Stefan
>
> ---------------------------------------------------------------------
> 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: [Vote] Format of "git" tags

Bernd Eckenfels
In reply to this post by Gilles Sadowski-2
Option_2+1

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: Gilles Sadowski <[hidden email]>
Gesendet: Wednesday, April 1, 2020 1:02:38 PM
An: Commons Developers List <[hidden email]>
Betreff: [Vote] Format of "git" tags

Hello.

This vote is a follow-up of the discussion that started in
another thread.[1]

As one of the many small steps towards convergence of
the release processes for all Commons components, it is
proposed that the same format be used when creating "git"
tags.[2]

As Gary noted (in the referred thread), the tag is namely used
when cloning a release candidate.[3]

Alternatives (using the yet-to-be-created tag for the release
candidate of the first beta version of [Numbers] as an example):

 [ ] Option 1: NUMBERS_1_0_BETA1_RC1
 [ ] Option 2: commons-numbers-1.0-beta1-rc1
 [ ] Option 3: commons-numbers_v1.0-beta1_rc1

Please give your choice of the format that should be used from
now on.

Thanks,
Gilles

[1] https://markmail.org/message/n457skstbxbirvhp
[2] https://git-scm.com/book/en/v2/Git-Basics-Tagging
[3] https://git-scm.com/docs/git-clone

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

Reply | Threaded
Open this post in threaded view
|

Re: [Vote] Format of "git" tags

Gilles Sadowski-2
In reply to this post by Stefan Bodewig
Hi.

Le mer. 1 avr. 2020 à 13:32, Stefan Bodewig <[hidden email]> a écrit :

>
> On 2020-04-01, Gilles Sadowski wrote:
>
> > Alternatives (using the yet-to-be-created tag for the release
> > candidate of the first beta version of [Numbers] as an example):
>
> >  [ ] Option 1: NUMBERS_1_0_BETA1_RC1
> >  [ ] Option 2: commons-numbers-1.0-beta1-rc1
> >  [ ] Option 3: commons-numbers_v1.0-beta1_rc1
>
> +0 to each of them as long as
> http://commons.apache.org/releases/prepare.html gets updated with the
> outcome.

"xml" files modified in revision 1876107.

Is there some step in order to regenerate the live site?

Regards,
Gilles

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

Reply | Threaded
Open this post in threaded view
|

[Result][Vote] Format of "git" tags

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

A common convention for naming tags (for releases and release
candidates) has been adopted.
"Option 2" gathered the following votes:
  +1 from Rob, Matt, Gary, Bruno and Bernd
  +0 from Stefan.

Thanks,
Gilles

Le mer. 1 avr. 2020 à 13:02, Gilles Sadowski <[hidden email]> a écrit :

>
> Hello.
>
> This vote is a follow-up of the discussion that started in
> another thread.[1]
>
> As one of the many small steps towards convergence of
> the release processes for all Commons components, it is
> proposed that the same format be used when creating "git"
> tags.[2]
>
> As Gary noted (in the referred thread), the tag is namely used
> when cloning a release candidate.[3]
>
> Alternatives (using the yet-to-be-created tag for the release
> candidate of the first beta version of [Numbers] as an example):
>
>  [ ] Option 1: NUMBERS_1_0_BETA1_RC1
>  [ ] Option 2: commons-numbers-1.0-beta1-rc1
>  [ ] Option 3: commons-numbers_v1.0-beta1_rc1
>
> Please give your choice of the format that should be used from
> now on.
>
> Thanks,
> Gilles
>
> [1] https://markmail.org/message/n457skstbxbirvhp
> [2] https://git-scm.com/book/en/v2/Git-Basics-Tagging
> [3] https://git-scm.com/docs/git-clone

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