On Sun, 18 Sep 2016 13:16:44 -0400, Rob Tompkins wrote:
On Sep 18, 2016, at 12:20 PM, Dennis E. Hamilton <dennis.hamil...@acm.org> wrote:

-----Original Message-----
From: Oliver Heger [mailto:oliver.he...@oliver-heger.de]
Sent: Sunday, September 18, 2016 06:37
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [VOTE][RC2] Release "Apache Commons RNG" version 1.0

Am 17.09.2016 um 18:13 schrieb Gary Gregory:
Hi All,

Gilles: I can see you are frustrated by the late comments and opinions
the code has been sitting in the repo for all to see. I hope we can
all of this amicably.

All: We have only one shot at 1.0, this will set the tone for a 1.x
If things change/mature/break enough then it becomes 2.0, but if it
too soon, then it might give the impression that our process is not

It seems we have a difference of opinion as to whether the current
code is
ready for 1.0.

Now that we have both sides engaged in this discussion, we can try to
resolve these differences in email agreements or in code changes.
Maybe the
-1 party could create Jiras to address specific issues, or should all
happen on the ML?

Currently only Gilles responded to the proposals of Emmanuel. I would
also be interested in the PoV of the other developers.



Rather than have this run around in circles and frustrate the great
work Gilles has provided in advancing Commons RNG, would it work to
call it 0.9 and get it out the door?

I say 0.9 because under norms for version numbers, the 0.*.* are
assumed to be vulnerable to breaking changes in interfaces -
signatures and behaviors.  And since there is apparently some
objection to the API and the prospect of breaking changes it
would be nice to (1) get this work in folks' hands and (2) get
to work on whatever needs to be done about the API.

I’ve been following the thread for some time here, and was looking
for a place to jump in. Dennis’ suggestion here seems like a good
middle ground that I had yet to consider. Are there any drawbacks in
doing this, aside from the annoying 50 steps that Gary referred to

If I'm not mistaken, there are, actually.

Case A: 0.9 is released with package name "o.a.c.rng"

 Case A1: There is a breaking change
 With what package name will 1.0 be released?

 Case A2: There is no code change
 We release 1.0, a major number change, but with the same
 Should users upgrade?  It will be trivial (dependency
 upgrade) but annoying.

Case B: 0.9 is released with a "beta" package name (e.g.

 Case B1: There is a breaking change
 1.0 is released with package name "o.a.c.rng".

 Case B2: There is no change
 Users will be forced to upgrade (change their code).
 It is less trivial and even more annoying.

So in this scenario, the only case where all is fine in the
end is when we assume (now) that there is something wrong
with the API.

But I don't see that the IDE argument should win over others
that favour the simplicity of the "create" method that takes
any supported seed type as argument vs one factory method per
implementation, or more probably one per implementation and
per seed type.
In the latter case, we'd go from 2 "create" methods (now) to
at least 15 methods, and the need for the caller to make the
seed conversion himself.  If we want to provide the syntactic
sugar of "automatic" conversion (through method overloading in
that case), the number of methods will explode to something
like 45:
 * an overload for the "native" seed type,
 * an overload for "long" (the "default" seed type which
   people are used to from "java.util.Random"),
 * an overload for "byte[]".

If not, the user will need to know the native type, even for
casual use, (which is a pain, especially when not using an
intelligent IDE).

Moreover, each new implementation will add 3 such factory
methods (requiring duplicating trivial unit tests).

If 1.0 is released, and I got it wrong, then we do the usual thing:
release 2.0 with package name "o.a.c.rng2".



I am making no assumptions about the quality of the API.  0.9 is
insurance until that argument and use by others can be settled.
Then the API discussion can happen in some constructive place far
better than the [VOTE] thread.

- Dennis

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

Reply via email to