You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Matt Juntunen <ma...@hotmail.com> on 2020/04/01 02:23:25 UTC

Re: [numbers] 1.0-B1 Release Proposal

Hi all,

After reading all of the comments, here is what I propose for moving forward:

  *   Use version number "1.0-beta1" instead of "1.0-B1". (Gary, were you planning on updating the versioning guidelines?)
  *   Create a new release branch named "1.0-beta1-release" from the "1.0-B1-release" branch I created earlier.
  *   Drop branch 1.0-B1-release.
  *   Drop tag NUMBERS_1_0_B1_RC1, since it never went up for a vote, has the wrong version number, and is not needed.
  *   Merge Windows build fixes from master and fix site issues previously mentioned.
  *   Create new RC1 and tag as NUMBERS_1_0_BETA1_RC1. (I like Gary's tag format but the format here with all uppercase letters and underscores seems to be used consistently across all commons projects.)
  *   Vote.

I'll start working on the build fixes locally, but I won't do any of the other changes until it seems like we have a consensus on this approach. Does anyone have any comments or objections?

Regards,
Matt J

________________________________
From: Gilles Sadowski <gi...@gmail.com>
Sent: Tuesday, March 31, 2020 5:53 PM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [numbers] 1.0-B1 Release Proposal

Le mar. 31 mars 2020 à 22:55, Gary Gregory <ga...@gmail.com> a écrit :
>
> On Tue, Mar 31, 2020 at 4:51 PM Gilles Sadowski <gi...@gmail.com>
> wrote:
>
> > Hi.
> >
> > Le mar. 31 mars 2020 à 22:30, Gary Gregory <ga...@gmail.com> a
> > écrit :
> > >
> > > On Tue, Mar 31, 2020 at 3:16 PM Gilles Sadowski <gi...@gmail.com>
> > > wrote:
> > >
> > > > > > [...]
> > > > > > I'm fine with improving the (common?) convention.
> > > > > >
> > > > > > Why not dropping the redundant reference to the component
> > > > > > and project, since they are in the repo's name?
> > > > > > And how about focusing on the tag's purpose by mentioning
> > > > > > it first?
> > > > > > Thus:
> > > > > >     rc1_v1.0-beta1
> > > > > >
> > > > >
> > > > > The argument for having the component name in the tag name is that
> > when
> > > > you
> > > > > clone the repo, you get a 'nice' directory name by default.
> > > > >
> > > >
> > > > Convincing.
> > > >
> > > > So, I suggest
> > > >
> > > > commons-numbers_v1.0-beta1_rc1
> > > >
> > >
> > > For me, I find the mix of - and _ lame and since we use - in component
> > > names, I prefer -'s for all separators.
> >
> > I beg to differ.
> > A hyphen is for joining, an underscore for separating, making
> > the string more parseable (both for humans and for scripts).
> >
>
> That's certainly not how Maven sees it, for example:
> commons-lang3-3.10-javadoc.jar
> <https://repo1.maven.org/maven2/org/apache/commons/commons-lang3/3.10/commons-lang3-3.10-javadoc.jar>

Not the same context: (git) tags vs (maven) artefacts.

> I'd rather we stick to known conventions and not invent yet another one.

I agree on the principle, but in the current case, you are the one
who proposes to depart from the convention which Commons has
been using since "forever". ;-)

I'm fine with whatever we decide, as long as we *all* agree to
use the same convention, and that it becomes a requirement
for subsequent RCs.

Regards,
Gilles

>
> Gary
>
>
> > > >
> > > > i.e.
> > > >
> > > > <component id>_v<version>[-beta<m>]_rc<n>
> > > >
> > > > OK?
> > > >
> > > > Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [numbers] 1.0-B1 Release Proposal

Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.

Le jeu. 2 avr. 2020 à 13:53, Matt Juntunen <ma...@hotmail.com> a écrit :
>
> I have this ready to go on branch 1.0-beta1. Based on the discussions and the git tag vote, I plan on using the tag "commons-numbers-1.0-beta1-rc1" for the release candidate

+1

> and "rel/commons-numbers-1.0-beta1" for the actual release.

Yes, but not until there is a release. :-)

> I'll wait until tomorrow before creating the actual release candidate in case anyone has any objections.
>
> Alex, I see you made some more commits to master (updating LICENSE and NOTICE file names and some changes to Complex). Should I pull those into the release?

Yes.
The least discrepancy with "master", the better.

Thanks,
Gilles

>>>> [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [numbers] 1.0-B1 Release Proposal

Posted by Matt Juntunen <ma...@hotmail.com>.
I have this ready to go on branch 1.0-beta1. Based on the discussions and the git tag vote, I plan on using the tag "commons-numbers-1.0-beta1-rc1" for the release candidate and "rel/commons-numbers-1.0-beta1" for the actual release. I'll wait until tomorrow before creating the actual release candidate in case anyone has any objections.

Alex, I see you made some more commits to master (updating LICENSE and NOTICE file names and some changes to Complex). Should I pull those into the release?

Regards,
Matt
________________________________
From: Matt Juntunen <ma...@hotmail.com>
Sent: Tuesday, March 31, 2020 10:23 PM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [numbers] 1.0-B1 Release Proposal

Hi all,

After reading all of the comments, here is what I propose for moving forward:

  *   Use version number "1.0-beta1" instead of "1.0-B1". (Gary, were you planning on updating the versioning guidelines?)
  *   Create a new release branch named "1.0-beta1-release" from the "1.0-B1-release" branch I created earlier.
  *   Drop branch 1.0-B1-release.
  *   Drop tag NUMBERS_1_0_B1_RC1, since it never went up for a vote, has the wrong version number, and is not needed.
  *   Merge Windows build fixes from master and fix site issues previously mentioned.
  *   Create new RC1 and tag as NUMBERS_1_0_BETA1_RC1. (I like Gary's tag format but the format here with all uppercase letters and underscores seems to be used consistently across all commons projects.)
  *   Vote.

I'll start working on the build fixes locally, but I won't do any of the other changes until it seems like we have a consensus on this approach. Does anyone have any comments or objections?

Regards,
Matt J

________________________________
From: Gilles Sadowski <gi...@gmail.com>
Sent: Tuesday, March 31, 2020 5:53 PM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [numbers] 1.0-B1 Release Proposal

Le mar. 31 mars 2020 à 22:55, Gary Gregory <ga...@gmail.com> a écrit :
>
> On Tue, Mar 31, 2020 at 4:51 PM Gilles Sadowski <gi...@gmail.com>
> wrote:
>
> > Hi.
> >
> > Le mar. 31 mars 2020 à 22:30, Gary Gregory <ga...@gmail.com> a
> > écrit :
> > >
> > > On Tue, Mar 31, 2020 at 3:16 PM Gilles Sadowski <gi...@gmail.com>
> > > wrote:
> > >
> > > > > > [...]
> > > > > > I'm fine with improving the (common?) convention.
> > > > > >
> > > > > > Why not dropping the redundant reference to the component
> > > > > > and project, since they are in the repo's name?
> > > > > > And how about focusing on the tag's purpose by mentioning
> > > > > > it first?
> > > > > > Thus:
> > > > > >     rc1_v1.0-beta1
> > > > > >
> > > > >
> > > > > The argument for having the component name in the tag name is that
> > when
> > > > you
> > > > > clone the repo, you get a 'nice' directory name by default.
> > > > >
> > > >
> > > > Convincing.
> > > >
> > > > So, I suggest
> > > >
> > > > commons-numbers_v1.0-beta1_rc1
> > > >
> > >
> > > For me, I find the mix of - and _ lame and since we use - in component
> > > names, I prefer -'s for all separators.
> >
> > I beg to differ.
> > A hyphen is for joining, an underscore for separating, making
> > the string more parseable (both for humans and for scripts).
> >
>
> That's certainly not how Maven sees it, for example:
> commons-lang3-3.10-javadoc.jar
> <https://repo1.maven.org/maven2/org/apache/commons/commons-lang3/3.10/commons-lang3-3.10-javadoc.jar>

Not the same context: (git) tags vs (maven) artefacts.

> I'd rather we stick to known conventions and not invent yet another one.

I agree on the principle, but in the current case, you are the one
who proposes to depart from the convention which Commons has
been using since "forever". ;-)

I'm fine with whatever we decide, as long as we *all* agree to
use the same convention, and that it becomes a requirement
for subsequent RCs.

Regards,
Gilles

>
> Gary
>
>
> > > >
> > > > i.e.
> > > >
> > > > <component id>_v<version>[-beta<m>]_rc<n>
> > > >
> > > > OK?
> > > >
> > > > Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org