Re: [RNG] modules vs projects

2016-09-30 Thread Gilles
On Fri, 30 Sep 2016 10:45:47 -0500, Brent Worden wrote: On Fri, Sep 30, 2016 at 10:02 AM, Gilles wrote: On Fri, 30 Sep 2016 09:41:44 +0200, Emmanuel Bourg wrote: - No immediate Jenkins feedback if a rng-core change breaks rng-utils I'm not sure I got

Re: [lang] Shuffling arrays

2016-09-30 Thread Gilles
On Fri, 30 Sep 2016 11:34:10 -0500, Matt Sicker wrote: I thought he meant that if your code works with either Random or SecureRandom, you're doing it wrong. They both have very different use cases, and the fact that SecureRandom extends Random contributes to the confusion. Indeed. [I should

Re: [lang] Shuffling arrays

2016-09-30 Thread Gilles
On Fri, 30 Sep 2016 15:02:40 +0200, Emmanuel Bourg wrote: Le 28/09/2016 à 15:28, Gilles a écrit : Conversely, using "SecureRandom" in place of a deterministic RNG is only useful in toy applications since the main feature (of non-secure RNGs) one usually needs is reproducibility. I guess the

Re: [weaver] 1.3 release process

2016-09-30 Thread Gary Gregory
Go for it! Gary On Fri, Sep 30, 2016 at 9:55 AM, Matt Benson wrote: > Just a note to let the community I plan to start rolling release candidates > in the near future. > > Matt > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate,

[weaver] 1.3 release process

2016-09-30 Thread Matt Benson
Just a note to let the community I plan to start rolling release candidates in the near future. Matt

Re: [lang] Shuffling arrays

2016-09-30 Thread Matt Sicker
I thought he meant that if your code works with either Random or SecureRandom, you're doing it wrong. They both have very different use cases, and the fact that SecureRandom extends Random contributes to the confusion. On 30 September 2016 at 08:02, Emmanuel Bourg wrote: > Le

Re: [RNG] modules vs projects

2016-09-30 Thread Gary Gregory
Hi All, [Note my careful use of the terms "project", "component", and "module"] Pardon my jumping in late... If some of this is leading to more than one commons-rng component within Apache Commons, I would be against that; Maven modules are a perfect match for this concept. Please allow me to

Re: [RNG] modules vs projects

2016-09-30 Thread Brent Worden
On Fri, Sep 30, 2016 at 10:02 AM, Gilles wrote: > On Fri, 30 Sep 2016 09:41:44 +0200, Emmanuel Bourg wrote: > >> >> - No immediate Jenkins feedback if a rng-core change breaks rng-utils > > I'm not sure I got that one. > If it means to copy the new "rng-core" over

Re: [RNG] modules vs projects

2016-09-30 Thread Gilles
On Fri, 30 Sep 2016 09:41:44 +0200, Emmanuel Bourg wrote: Le 29/09/2016 à 13:59, Gilles a écrit : What you are arguing here is that if "some-lib" is upgraded, then the JDK must change version too! Does that (extreme) comparison make the issue clearer? No, because it isn't comparable to our

Re: [RNG] modules vs projects

2016-09-30 Thread Gilles
On Fri, 30 Sep 2016 09:49:52 +0200, Emmanuel Bourg wrote: Le 29/09/2016 à 14:01, Gilles a écrit : ​I think other modules will be somehow dependent on rng-core, so change in core will require additional release of the module.​ Wrong! See previous post(s). Actually Artem is right. Changes

Re: [lang] Shuffling arrays

2016-09-30 Thread Emmanuel Bourg
Le 28/09/2016 à 15:28, Gilles a écrit : > Conversely, using "SecureRandom" in place of a deterministic > RNG is only useful in toy applications since the main feature > (of non-secure RNGs) one usually needs is reproducibility. I guess the Tomcat developers will love hearing they are building a

Re: [RNG] java.util.Random vs independent interface

2016-09-30 Thread Emmanuel Bourg
Le 28/09/2016 à 14:59, Gilles a écrit : > This will lead to unexpected behaviour. > For example, calling "setSeed" on the returned "Random" instance, > will have no effect. > > This will generate bug reports that can't be fixed without > resorting to very ugly workaround that have nothing to do

Re: [COMPRESS] [MATH] [VALIDATOR] [PARENT] Removing old releases from dist?

2016-09-30 Thread Stefan Bodewig
On 2016-09-30, Stian Soiland-Reyes wrote: > But there are also these which I don't think we need to keep: > compress/source/commons-compress-1.11-src.tar.gz (1.12 newer) You are correct, I must have forgotten to remove it after I cut the last release. > OK if I remove these? Silence means yes.

[COMPRESS] [MATH] [VALIDATOR] [PARENT] Removing old releases from dist?

2016-09-30 Thread Stian Soiland-Reyes
I had a quick look at older versions in http://www.apache.org/dist/commons/ All old versions are in http://archive.apache.org/dist/commons/ - and we tend to keep just the last release of a minor version. Some of these have multiple major versions or provide an older minor version on purpose,

Re: [RNG] modules vs projects

2016-09-30 Thread Emmanuel Bourg
Le 29/09/2016 à 14:01, Gilles a écrit : >> ​I think other modules will be somehow dependent on rng-core, so change >> in core will require additional release of the module.​ > > Wrong! > > See previous post(s). Actually Artem is right. Changes in rng-core are likely to be used in rng-utils.

Re: [RNG] modules vs projects

2016-09-30 Thread Emmanuel Bourg
Le 29/09/2016 à 13:59, Gilles a écrit : > What you are arguing here is that if "some-lib" is > upgraded, then the JDK must change version too! > > Does that (extreme) comparison make the issue clearer? No, because it isn't comparable to our situation. rng-core and rng-utils are developed by the

Re: [RNG] modules vs projects

2016-09-30 Thread Emmanuel Bourg
Le 29/09/2016 à 12:23, Gilles a écrit : >> And multiple projects would hypothetically ease one migration every five >> years? > > This would happen for _every_ release. How do you come to this conclusion? We are talking about an incompatible update, the kind of update that forces to change the