Re: [Math] Release hurdles

[Gilles Sadowski]

Hi.

So using the insecure way of passing a password on the command-line,
I'm one step further:  Which files to delete from Nexus (and how).
Why can't we seem to avoid uploading unnecessary files there?
Is the problem with Nexus or the release process or maven?
Now that they are there, is there still no other way than to pick them
up one at a time, click on "Delete" and then click for confirmation (that
make it largely the most time consuming task of the process)?

Please confirm that only the
  *.jar
  *.pom
  *.cyclonedx.xml
  *.cyclone.json
  *.spdx.json
files (and their associated fingerprint and checksum files) should remain.

Regards,
Gilles

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

Re: [Math] Release hurdles

[Gilles Sadowski]

Le jeu. 15 déc. 2022 à 10:53, Gilles Sadowski  a écrit :
>
> Hi.
>
> So using the insecure way of passing a password on the command-line,
> I'm one step further:  Which files to delete from Nexus (and how).
> Why can't we seem to avoid uploading unnecessary files there?
> Is the problem with Nexus or the release process or maven?
> Now that they are there, is there still no other way than to pick them
> up one at a time, click on "Delete" and then click for confirmation (that
> make it largely the most time consuming task of the process)?
>
> Please confirm that only the
>   *.jar
>   *.pom
>   *.cyclonedx.xml
>   *.cyclone.json
>   *.spdx.json
> files (and their associated fingerprint and checksum files) should remain.

Also, there is no JAR file in the
  commons-math-examples
folder on Nexus; is it OK to delete it entirely?

> Regards,
> Gilles

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

Re: [Math] Release hurdles

[Gilles Sadowski]

Le jeu. 15 déc. 2022 à 11:01, Gilles Sadowski  a écrit :
>
> Le jeu. 15 déc. 2022 à 10:53, Gilles Sadowski  a écrit :
> >
> > Hi.
> >
> > So using the insecure way of passing a password on the command-line,
> > I'm one step further:  Which files to delete from Nexus (and how).
> > Why can't we seem to avoid uploading unnecessary files there?
> > Is the problem with Nexus or the release process or maven?
> > Now that they are there, is there still no other way than to pick them
> > up one at a time, click on "Delete" and then click for confirmation (that
> > make it largely the most time consuming task of the process)?
> >
> > Please confirm that only the
> >   *.jar
> >   *.pom
> >   *.cyclonedx.xml
> >   *.cyclone.json
> >   *.spdx.json
> > files (and their associated fingerprint and checksum files) should remain.
>
> Also, there is no JAR file in the
>   commons-math-examples
> folder on Nexus; is it OK to delete it entirely?

And what about the "*site.xml.*" files in the commons-math-parent" folder?
To be deleted too?

>
> > Regards,
> > Gilles

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

Re: [Math] Release hurdles

[Gilles Sadowski]

Le jeu. 15 déc. 2022 à 11:01, Gilles Sadowski  a écrit :
>
> Le jeu. 15 déc. 2022 à 10:53, Gilles Sadowski  a écrit :
> >
> > Hi.
> >
> > So using the insecure way of passing a password on the command-line,
> > I'm one step further:  Which files to delete from Nexus (and how).
> > Why can't we seem to avoid uploading unnecessary files there?
> > Is the problem with Nexus or the release process or maven?
> > Now that they are there, is there still no other way than to pick them
> > up one at a time, click on "Delete" and then click for confirmation (that
> > make it largely the most time consuming task of the process)?
> >
> > Please confirm that only the
> >   *.jar
> >   *.pom
> >   *.cyclonedx.xml
> >   *.cyclone.json
> >   *.spdx.json
> > files (and their associated fingerprint and checksum files) should remain.
>
> Also, there is no JAR file in the
>   commons-math-examples
> folder on Nexus; is it OK to delete it entirely?

I guess not: It is the parent of modules that may have artefacts.
Ditto for "examples-kmeans" (no JAR, but parent of "examples-kmeans-image"
that has a JAR).

It is cleaner to have a separate module for each "mini-application" (which a
user can then easily run).
However if we have to perform this "manual" deletion of spurious file for each
release), it will be much less error-prone to put all the examples in the same
module (and use the "subcommand" feature of "picocli").

Regards,
Gilles

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

Re: [Math] Release hurdles

[Alex Herbert]

On Thu, 15 Dec 2022 at 10:24, Gilles Sadowski  wrote:
>
> Le jeu. 15 déc. 2022 à 11:01, Gilles Sadowski  a écrit :
> >
> > Le jeu. 15 déc. 2022 à 10:53, Gilles Sadowski  a 
> > écrit :
> > >
> > > Hi.
> > >
> > > So using the insecure way of passing a password on the command-line,
> > > I'm one step further:  Which files to delete from Nexus (and how).
> > > Why can't we seem to avoid uploading unnecessary files there?
> > > Is the problem with Nexus or the release process or maven?
> > > Now that they are there, is there still no other way than to pick them
> > > up one at a time, click on "Delete" and then click for confirmation (that
> > > make it largely the most time consuming task of the process)?

Yes. It is slow for a large multi-module project to remove all these.
I think this is due to the gpg deploy goal in maven signing extras. I
had to delete extra files for the BOM module in numbers and rng which
uploaded extras.

> > >
> > > Please confirm that only the
> > >   *.jar
> > >   *.pom
> > >   *.cyclonedx.xml
> > >   *.cyclone.json
> > >   *.spdx.json
> > > files (and their associated fingerprint and checksum files) should remain.

Yes. See a recent single jar release for an example [1].

> >
> > Also, there is no JAR file in the
> >   commons-math-examples
> > folder on Nexus; is it OK to delete it entirely?
>
> And what about the "*site.xml.*" files in the commons-math-parent" folder?
> To be deleted too?

I do not see the need for these. But they are usually left for any pom
files (see [2, 3]). This is probably due to them being harmless and it
being a pain to remove them. I think I removed them from one rng
release I performed but not the most recent one.

Alex

[1] https://repo1.maven.org/maven2/org/apache/commons/commons-text/1.10.0/
[2] https://repo1.maven.org/maven2/org/apache/commons/commons-parent/55/
[3] https://repo1.maven.org/maven2/org/apache/commons/commons-rng-parent/1.5/


>
> >
> > > Regards,
> > > Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [Math] Release hurdles

[Alex Herbert]

On Thu, 15 Dec 2022 at 10:52, Gilles Sadowski  wrote:
>
> Le jeu. 15 déc. 2022 à 11:01, Gilles Sadowski  a écrit :
> >
> > Le jeu. 15 déc. 2022 à 10:53, Gilles Sadowski  a 
> > écrit :
> > >
> > > Hi.
> > >
> > > So using the insecure way of passing a password on the command-line,
> > > I'm one step further:  Which files to delete from Nexus (and how).
> > > Why can't we seem to avoid uploading unnecessary files there?
> > > Is the problem with Nexus or the release process or maven?
> > > Now that they are there, is there still no other way than to pick them
> > > up one at a time, click on "Delete" and then click for confirmation (that
> > > make it largely the most time consuming task of the process)?
> > >
> > > Please confirm that only the
> > >   *.jar
> > >   *.pom
> > >   *.cyclonedx.xml
> > >   *.cyclone.json
> > >   *.spdx.json
> > > files (and their associated fingerprint and checksum files) should remain.
> >
> > Also, there is no JAR file in the
> >   commons-math-examples
> > folder on Nexus; is it OK to delete it entirely?
>
> I guess not: It is the parent of modules that may have artefacts.
> Ditto for "examples-kmeans" (no JAR, but parent of "examples-kmeans-image"
> that has a JAR).
>
> It is cleaner to have a separate module for each "mini-application" (which a
> user can then easily run).
> However if we have to perform this "manual" deletion of spurious file for each
> release), it will be much less error-prone to put all the examples in the same
> module (and use the "subcommand" feature of "picocli").

For the other multi-module projects we decided not to upload artifacts
to nexus. These jars have no binary compatibility commitment.

They are included using an 'examples' profile when you build the site.
But they should not be in the release profile. The latest release of
statistics, geometry, rng and numbers did not upload the examples to
Nexus. They would be in the source distribution only.

Also note that you may wish to delete some modules from the release.
For example, is the new ga module ready? Given this is a beta release
then this removal may not be necessary as it is not a final cut.

Alex

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

Re: [Math] Release hurdles

[Gilles Sadowski]

Hi.

Le jeu. 15 déc. 2022 à 12:00, Alex Herbert  a écrit :
>
> On Thu, 15 Dec 2022 at 10:52, Gilles Sadowski  wrote:
> >
> > Le jeu. 15 déc. 2022 à 11:01, Gilles Sadowski  a 
> > écrit :
> > >
> > > Le jeu. 15 déc. 2022 à 10:53, Gilles Sadowski  a 
> > > écrit :
> > > >
> > > > Hi.
> > > >
> > > > So using the insecure way of passing a password on the command-line,
> > > > I'm one step further:  Which files to delete from Nexus (and how).
> > > > Why can't we seem to avoid uploading unnecessary files there?
> > > > Is the problem with Nexus or the release process or maven?
> > > > Now that they are there, is there still no other way than to pick them
> > > > up one at a time, click on "Delete" and then click for confirmation 
> > > > (that
> > > > make it largely the most time consuming task of the process)?
> > > >
> > > > Please confirm that only the
> > > >   *.jar
> > > >   *.pom
> > > >   *.cyclonedx.xml
> > > >   *.cyclone.json
> > > >   *.spdx.json
> > > > files (and their associated fingerprint and checksum files) should 
> > > > remain.
> > >
> > > Also, there is no JAR file in the
> > >   commons-math-examples
> > > folder on Nexus; is it OK to delete it entirely?
> >
> > I guess not: It is the parent of modules that may have artefacts.
> > Ditto for "examples-kmeans" (no JAR, but parent of "examples-kmeans-image"
> > that has a JAR).
> >
> > It is cleaner to have a separate module for each "mini-application" (which a
> > user can then easily run).
> > However if we have to perform this "manual" deletion of spurious file for 
> > each
> > release), it will be much less error-prone to put all the examples in the 
> > same
> > module (and use the "subcommand" feature of "picocli").
>
> For the other multi-module projects we decided not to upload artifacts
> to nexus. These jars have no binary compatibility commitment.
>
> They are included using an 'examples' profile when you build the site.

There is no such profile in the [Math] POM.
The line
---CUT---
commons-math-examples
---CUT---
is in the "" section.

Also, I've performed a maven command, noted in earlier messages, that
did not specify "site" (or does the "deploy" target depend on "site"?).

> But they should not be in the release profile. The latest release of
> statistics, geometry, rng and numbers did not upload the examples to
> Nexus. They would be in the source distribution only.

So, for this release, can I just delete all the "*examples*" folders on
Nexus?
[Then for the next ones, the upload should be disabled like for the
other components.]

>
> Also note that you may wish to delete some modules from the release.
> For example, is the new ga module ready?

No. I could not reach consensus with the contributor yet (on design
issues), and there hasn't been any feedback to my last message
(sent 2 months ago to this ML) asking precise questions in order to
go forward.

> Given this is a beta release
> then this removal may not be necessary as it is not a final cut.

The GA module is not in the "master" branch.

Regards,
Gilles

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

[ANNOUNCE] Apache Commons Parent 55

[Gary Gregory]

[To the dev list only]
The Apache Commons Parent team is pleased to announce the release of
Apache Commons Parent 55.

The Apache Commons Parent POM provides common settings for all Apache
Commons components.

Version 55: Maintenance and update dependencies

Historical list of changes:
https://commons.apache.org/proper/commons-parent/changes-report.html

For complete information on Apache Commons Parent, including
instructions on how to submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Commons
Parent website:

https://commons.apache.org/proper/commons-parent/

Gary

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

[REPORT] Board report for this quarter

[Gary D. Gregory]

This is what I submitted for our board report for this quarter:

## Description:
The mission of Apache Commons is the creation and maintenance of Java focused 
reusable libraries and components

## Issues:
There are no issues requiring board attention.

## Membership Data:
Apache Commons was founded 2007-06-19 (15 years ago)
There are currently 149 committers and 42 PMC members in this project.
The Committer-to-PMC ratio is roughly 5:2.

Community changes, past quarter:
- No new PMC members. Last addition was Matt Juntunen on 2021-06-25.
- No new committers. Last addition was Claude Warren on 2022-02-01.

## Project Activity:
The Apache Commons teams has been following up of security reports, bug fixes,
adding features, and have released many components:

- PARENT-55 was released on 2022-12-11.
- BCEL-6.7.0 was released on 2022-12-06.
- STATISTICS-1.0 was released on 2022-12-06.
- NET-3.9.0 was released on 2022-12-01.
- DAEMON-1.3.3 was released on 2022-11-29.
- BCEL-6.6.1 was released on 2022-11-03.
- NUMBERS-1.1 was released on 2022-11-01.
- COMPRESS-1.22 was released on 2022-10-31.
- BCEL-6.6.0 was released on 2022-10-12.
- DAEMON-1.3.2 was released on 2022-10-10.
- RNG-1.5 was released on 2022-10-10.
- TEXT-1.10.0 was released on 2022-09-29.

The latest release of Apache Commons BCEL will allow Apache Xalan to continue 
its release process.

## Community Health:
The community is active in many components with commit activity much higher
this quarter with a 40% increase, all the while mailing list activity is down.
We are seeing a lot of input from GitHub PRs.

Gary

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

Re: [FILEUPLOAD] State of the 1.6 branch

[Mark Thomas]

On 14/12/2022 12:12, Gilles Sadowski wrote:

Hi.

Le mer. 14 déc. 2022 à 12:25, Gary Gregory  a écrit :


I would create a branch called "1.x" instead and bump the version in the
POM to 1.5.0.

FYI, I've been using the x.y.z version format in most of not all components
I work on, I find that it sets expectations better, for me anyway.


IIRC, the convention is to use "x.y" if "z" is "0".


I have a very strong perference for always including the z component 
even if it is zero. That said, for consistency I intend to follow 
whatever pattern (I haven't looked yet) file upload used for the 
previous 1.x releases.



If a third number refers to "patch" or "bug fix", and there hasn't
been any, it is rather more confusing.


I disagree. I see greater confusion between 1.y referring to the 
specific 1.y(.0) release or the series of 1.y releases. If the .z 
component is always present, there is no opporutnity for confusion.



IMO, this is the kind of thing that should be consistent across all
releases within a project; so departing from the common (and
Commons') practice should not occur without a vote.


If the process wasn't established with a VOTE there there is no need for 
a VOTE to deviate from it.


It seems reasonable that there should be a consistent versioning format 
but it isn't clear if we'd be able to reach consensus on what that 
should be.



Perhaps the same remark about naming (git) "tags".


Ditto.

Mark

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

Re: [FILEUPLOAD] State of the 1.6 branch

[Gary Gregory]

FYI, for all the components I've been working on, I have used the x.y.z
format.

Gary

On Thu, Dec 15, 2022, 11:36 Mark Thomas  wrote:

> On 14/12/2022 12:12, Gilles Sadowski wrote:
> > Hi.
> >
> > Le mer. 14 déc. 2022 à 12:25, Gary Gregory  a
> écrit :
> >>
> >> I would create a branch called "1.x" instead and bump the version in the
> >> POM to 1.5.0.
> >>
> >> FYI, I've been using the x.y.z version format in most of not all
> components
> >> I work on, I find that it sets expectations better, for me anyway.
> >
> > IIRC, the convention is to use "x.y" if "z" is "0".
>
> I have a very strong perference for always including the z component
> even if it is zero. That said, for consistency I intend to follow
> whatever pattern (I haven't looked yet) file upload used for the
> previous 1.x releases.
>
> > If a third number refers to "patch" or "bug fix", and there hasn't
> > been any, it is rather more confusing.
>
> I disagree. I see greater confusion between 1.y referring to the
> specific 1.y(.0) release or the series of 1.y releases. If the .z
> component is always present, there is no opporutnity for confusion.
>
> > IMO, this is the kind of thing that should be consistent across all
> > releases within a project; so departing from the common (and
> > Commons') practice should not occur without a vote.
>
> If the process wasn't established with a VOTE there there is no need for
> a VOTE to deviate from it.
>
> It seems reasonable that there should be a consistent versioning format
> but it isn't clear if we'd be able to reach consensus on what that
> should be.
>
> > Perhaps the same remark about naming (git) "tags".
>
> Ditto.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] Release hurdles

[Alex Herbert]

On Thu, 15 Dec 2022 at 11:28, Gilles Sadowski  wrote:
>
> Hi.
>
> Le jeu. 15 déc. 2022 à 12:00, Alex Herbert  a écrit 
> :
> >
> > On Thu, 15 Dec 2022 at 10:52, Gilles Sadowski  wrote:
> > >
> > > Le jeu. 15 déc. 2022 à 11:01, Gilles Sadowski  a 
> > > écrit :
> > > >
> > > > Le jeu. 15 déc. 2022 à 10:53, Gilles Sadowski  a 
> > > > écrit :
> > > > >
> > > > > Hi.
> > > > >
> > > > > So using the insecure way of passing a password on the command-line,
> > > > > I'm one step further:  Which files to delete from Nexus (and how).
> > > > > Why can't we seem to avoid uploading unnecessary files there?
> > > > > Is the problem with Nexus or the release process or maven?
> > > > > Now that they are there, is there still no other way than to pick them
> > > > > up one at a time, click on "Delete" and then click for confirmation 
> > > > > (that
> > > > > make it largely the most time consuming task of the process)?
> > > > >
> > > > > Please confirm that only the
> > > > >   *.jar
> > > > >   *.pom
> > > > >   *.cyclonedx.xml
> > > > >   *.cyclone.json
> > > > >   *.spdx.json
> > > > > files (and their associated fingerprint and checksum files) should 
> > > > > remain.
> > > >
> > > > Also, there is no JAR file in the
> > > >   commons-math-examples
> > > > folder on Nexus; is it OK to delete it entirely?
> > >
> > > I guess not: It is the parent of modules that may have artefacts.
> > > Ditto for "examples-kmeans" (no JAR, but parent of "examples-kmeans-image"
> > > that has a JAR).
> > >
> > > It is cleaner to have a separate module for each "mini-application" 
> > > (which a
> > > user can then easily run).
> > > However if we have to perform this "manual" deletion of spurious file for 
> > > each
> > > release), it will be much less error-prone to put all the examples in the 
> > > same
> > > module (and use the "subcommand" feature of "picocli").
> >
> > For the other multi-module projects we decided not to upload artifacts
> > to nexus. These jars have no binary compatibility commitment.
> >
> > They are included using an 'examples' profile when you build the site.
>
> There is no such profile in the [Math] POM.
> The line
> ---CUT---
> commons-math-examples
> ---CUT---
> is in the "" section.
>
> Also, I've performed a maven command, noted in earlier messages, that
> did not specify "site" (or does the "deploy" target depend on "site"?).

Our current release howto states that the site goal is required for
the commons-release plugin to stage the site. So I always run it and
didn't know you could omit it. If you do have a staged site then you
manually delete it (it is only the site for the parent pom) and then
stage the correct multi-module site built with the examples. If you
did not have to use the 'site' goal then the release guide can be
updated. I'll make a note to try without the site goal on the next
release.

>
> > But they should not be in the release profile. The latest release of
> > statistics, geometry, rng and numbers did not upload the examples to
> > Nexus. They would be in the source distribution only.
>
> So, for this release, can I just delete all the "*examples*" folders on
> Nexus?
> [Then for the next ones, the upload should be disabled like for the
> other components.]

If Nexus allows you then yes. I don't see a problem with it still
being in the parent pom since that will only affect building the
project. No-one will do that from downloaded artifacts.

Alex

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

Re: [FILEUPLOAD] State of the 1.6 branch

[Gilles Sadowski]

Hi.

Le jeu. 15 déc. 2022 à 17:36, Mark Thomas  a écrit :
>
> On 14/12/2022 12:12, Gilles Sadowski wrote:
> > Hi.
> >
> > Le mer. 14 déc. 2022 à 12:25, Gary Gregory  a écrit 
> > :
> >>
> >> I would create a branch called "1.x" instead and bump the version in the
> >> POM to 1.5.0.
> >>
> >> FYI, I've been using the x.y.z version format in most of not all components
> >> I work on, I find that it sets expectations better, for me anyway.
> >
> > IIRC, the convention is to use "x.y" if "z" is "0".
>
> I have a very strong perference for always including the z component
> even if it is zero. That said, for consistency I intend to follow
> whatever pattern (I haven't looked yet) file upload used for the
> previous 1.x releases.
>
> > If a third number refers to "patch" or "bug fix", and there hasn't
> > been any, it is rather more confusing.
>
> I disagree. I see greater confusion between 1.y referring to the
> specific 1.y(.0) release or the series of 1.y releases. If the .z
> component is always present, there is no opporutnity for confusion.
>
> > IMO, this is the kind of thing that should be consistent across all
> > releases within a project; so departing from the common (and
> > Commons') practice should not occur without a vote.
>
> If the process wasn't established with a VOTE there there is no need for
> a VOTE to deviate from it.
>
> It seems reasonable that there should be a consistent versioning format
> but it isn't clear if we'd be able to reach consensus on what that
> should be.
>
> > Perhaps the same remark about naming (git) "tags".
>
> Ditto.

My point is: either we collectively follow (informal) convention, or
we propose a change, possibly with a vote to make it a formal
convention.

I don't mind changing the version naming scheme because
having a convention is beneficial (meaning: All components
should do the same, to avoid confusion).

For example, a few years ago, an alternative model was
proposed for git development (and used in the Commons Math
repository).  Notably, in that model, the "master" branch was
named "development".
That proposal was criticized, not on the merit of the model, but
on the sole fact that the (informal) convention was to have a
"master" branch.
And the experiment stopped, just to maintain consistency with
the other components whose contributors did not see it useful
to depart from the convention.

Gilles

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

Re: [FILEUPLOAD] State of the 1.6 branch

[Jochen Wiedmann]

On Wed, Dec 14, 2022 at 12:20 PM Mark Thomas  wrote:

> - Delete the b2_0 branch
> - Move the head of the b1_4 branch to the 1.4 tag
> - Update the b1_4 branch for development of 1.4.1
>(or should that be 1.5 and start a new branch?)
> - Back-port my recent file count limit change

If you can do that: Please, do!

Jochen


-- 
Philosophy is useless, theology is worse. (Industrial Disease, Dire Straits)

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

[VOTE][RC1] Release Commons Math 4.0-beta1

[Gilles Sadowski]

Hello.

This is a VOTE for releasing Apache Commons Math v4.0-beta1 (from RC1).
[Thanks for the help to get there!]

Tag name:
  commons-math-4.0-beta1-RC1

  Command for checking out the project corresponding to this tag:
$ git clone https://gitbox.apache.org/repos/asf/commons-math.git
--branch commons-math-4.0-beta1-RC1

  From within the "commons-math" directory created by the above command, you
  can
   1. check the tag signature with the command
 $ git tag -v commons-math-4.0-beta1-RC1

   2. build the project[1] with the command
 $ mvn

Tag URL:
  
https://gitbox.apache.org/repos/asf?p=commons-math.git;a=commit;h=12ad3420a77611557603d1c7893d588610b2463a

Commit ID the tag points at:
  12ad3420a77611557603d1c7893d588610b2463a

Site:
  http://home.apache.org/~erans/commons-math-4.0-beta1-site/

Distribution files and release notes:
  https://dist.apache.org/repos/dist/dev/commons/math/

  To verify the integrity of the distribution files, you can

  1. download them with the command
 $ wget -nH --cut-dirs=8 \

https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/binaries/commons-math-4.0-beta1-bin.tar.gz
\

https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/binaries/commons-math-4.0-beta1-bin.zip
\

https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/source/commons-math-4.0-beta1-src.tar.gz
\

https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/source/commons-math-4.0-beta1-src.zip

  2. copy/paste the following excerpt (hash of the distribution files)
 into a text file (say "sha512.txt"):
---CUT---
#  
4a535ba815bd74eab4890d2a99ecfbe719927521b547119d68b03d87e6984f6ca41b9ee66cd4bd37bfc77762f0146227b7bd4a2157500aabfa20ce674fc9f8ab
commons-math-4.0-beta1-bin.tar.gz
3951e7d287032cb2beb966a5259c5ce6c64830fa9570a4659e4e36b74eecfd941ccc8c729dff1b9db1d695301e6a83e2ec35e49c54520c35d93146bfcafcf024
commons-math-4.0-beta1-bin.zip
668f552c444c7328bfb4e73bfba031e00d56212fc38a5d587ac9809ae63547b1caec7edb46a808dd62054601aaca696c3afa9fc4b6e5daa38d8c0db0f31a2ccd
commons-math-4.0-beta1-src.tar.gz
829be0c697a225087442b4b2b5ffdb8cbc337ab4d170b2a815f231528795278b68612bf1cdd6ace2e68880556789d960c07f19c42c6329165ebb2d79426337f8
commons-math-4.0-beta1-src.zip
---CUT---

   3. run the command
  $ sha512sum -c sha512.txt

KEYS file to check signatures:
  http://www.apache.org/dist/commons/KEYS

Maven artefacts:
  https://repository.apache.org/content/repositories/orgapachecommons-1613/

[ ] +1 Release it.
[ ] +0 Go ahead; I don't care.
[ ] -0 There are a few minor glitches: ...
[ ] -1 No, do not release it because ...

This vote will be open for at least 72 hours.

Best regards,
Gilles

[1] Tested with
$ mvn --version
Apache Maven 3.6.3
Maven home: /usr/share/maven
Java version: 11.0.16, vendor: Debian, runtime:
/usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.10.0-17-amd64", arch: "amd64", family: "unix"

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

Re: [VOTE][RC1] Release Commons Math 4.0-beta1

[Bruno Kinoshita]

 [x] +1 Release it.

Didn't have time to look at all reports, so ignored the legacy modules, and
looked briefly just at spotbugs/rat/checkstyle/pmd. Forgot to check
coverage. But it's looking good for a beta release IMO.

Built from tag with `mvn` on:

Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
Maven home: /opt/apache-maven-3.8.5
Java version: 17.0.5, vendor: Private Build, runtime:
/usr/lib/jvm/java-17-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.15.0-56-generic", arch: "amd64", family:
"unix"

Cheers

Bruno

On Thu, 15 Dec 2022 at 20:10, Gilles Sadowski  wrote:

> Hello.
>
> This is a VOTE for releasing Apache Commons Math v4.0-beta1 (from RC1).
> [Thanks for the help to get there!]
>
> Tag name:
>   commons-math-4.0-beta1-RC1
>
>   Command for checking out the project corresponding to this tag:
> $ git clone https://gitbox.apache.org/repos/asf/commons-math.git
> --branch 
> commons-math-4.0-beta1-RC1
>
>   From within the "commons-math" directory created by the above command,
> you
>   can
>1. check the tag signature with the command
>  $ git tag -v commons-math-4.0-beta1-RC1
>
>2. build the project[1] with the command
>  $ mvn
>
> Tag URL:
>
> https://gitbox.apache.org/repos/asf?p=commons-math.git;a=commit;h=12ad3420a77611557603d1c7893d588610b2463a
>
> Commit ID the tag points at:
>   12ad3420a77611557603d1c7893d588610b2463a
>
> Site:
>   http://home.apache.org/~erans/commons-math-4.0-beta1-site/
>
> Distribution files and release notes:
>   https://dist.apache.org/repos/dist/dev/commons/math/
>
>   To verify the integrity of the distribution files, you can
>
>   1. download them with the command
>  $ wget -nH --cut-dirs=8 \
>
> https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/binaries/commons-math-4.0-beta1-bin.tar.gz
> \
>
> https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/binaries/commons-math-4.0-beta1-bin.zip
> \
>
> https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/source/commons-math-4.0-beta1-src.tar.gz
> \
>
> https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/source/commons-math-4.0-beta1-src.zip
>
>   2. copy/paste the following excerpt (hash of the distribution files)
>  into a text file (say "sha512.txt"):
> ---CUT---
> #  
>
> 4a535ba815bd74eab4890d2a99ecfbe719927521b547119d68b03d87e6984f6ca41b9ee66cd4bd37bfc77762f0146227b7bd4a2157500aabfa20ce674fc9f8ab
> commons-math-4.0-beta1-bin.tar.gz
>
> 3951e7d287032cb2beb966a5259c5ce6c64830fa9570a4659e4e36b74eecfd941ccc8c729dff1b9db1d695301e6a83e2ec35e49c54520c35d93146bfcafcf024
> commons-math-4.0-beta1-bin.zip
>
> 668f552c444c7328bfb4e73bfba031e00d56212fc38a5d587ac9809ae63547b1caec7edb46a808dd62054601aaca696c3afa9fc4b6e5daa38d8c0db0f31a2ccd
> commons-math-4.0-beta1-src.tar.gz
>
> 829be0c697a225087442b4b2b5ffdb8cbc337ab4d170b2a815f231528795278b68612bf1cdd6ace2e68880556789d960c07f19c42c6329165ebb2d79426337f8
> commons-math-4.0-beta1-src.zip
> ---CUT---
>
>3. run the command
>   $ sha512sum -c sha512.txt
>
> KEYS file to check signatures:
>   http://www.apache.org/dist/commons/KEYS
>
> Maven artefacts:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1613/
>
> [ ] +1 Release it.
> [ ] +0 Go ahead; I don't care.
> [ ] -0 There are a few minor glitches: ...
> [ ] -1 No, do not release it because ...
>
> This vote will be open for at least 72 hours.
>
> Best regards,
> Gilles
>
> [1] Tested with
> $ mvn --version
> Apache Maven 3.6.3
> Maven home: /usr/share/maven
> Java version: 11.0.16, vendor: Debian, runtime:
> /usr/lib/jvm/java-11-openjdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.10.0-17-amd64", arch: "amd64", family: "unix"
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>