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
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
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
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,
Just a note to let the community I plan to start rolling release candidates
in the near future.
Matt
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
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
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
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
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
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
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
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.
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,
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.
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
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
17 matches
Mail list logo