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
when
the code has been sitting in the repo for all to see. I hope we
can
resolve
all of this amicably.
All: We have only one shot at 1.0, this will set the tone for a
1.x
line.
If things change/mature/break enough then it becomes 2.0, but if
it
happens
too soon, then it might give the impression that our process is
not
mature.
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
this
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.
Oliver
[orcmid]
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
earlier?
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
contents.
Should users upgrade? It will be trivial (dependency
upgrade) but annoying.
Case B: 0.9 is released with a "beta" package name (e.g.
"o.a.c.rng.beta")
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).
However:
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".
Gilles
-Rob
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
