You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Dennis E. Hamilton" <de...@acm.org> on 2016/09/18 16:20:11 UTC
[DISCUSS][VOTE][RC2] Release "Apache Commons RNG" version 1.0
> -----Original Message-----
> From: Oliver Heger [mailto:oliver.heger@oliver-heger.de]
> Sent: Sunday, September 18, 2016 06:37
> To: Commons Developers List <de...@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 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][VOTE][RC2] Release "Apache Commons RNG" version 1.0
Posted by Rob Tompkins <ch...@gmail.com>.
> On Sep 18, 2016, at 12:20 PM, Dennis E. Hamilton <de...@acm.org> wrote:
>
>
>
>> -----Original Message-----
>> From: Oliver Heger [mailto:oliver.heger@oliver-heger.de]
>> Sent: Sunday, September 18, 2016 06:37
>> To: Commons Developers List <de...@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.
Oh, I forgot to say that I’m +1 for either 1.0 or 0.9. It just felt like 0.9 set fairly reasonable middle ground.
-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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[RNG] About releasing 0.9 (Was: [DISCUSS][VOTE][RC2] ...)
Posted by Gilles <gi...@harfang.homelinux.org>.
On Sun, 18 Sep 2016 13:16:44 -0400, Rob Tompkins wrote:
>> On Sep 18, 2016, at 12:20 PM, Dennis E. Hamilton
>> <de...@acm.org> wrote:
>>
>>
>>
>>> -----Original Message-----
>>> From: Oliver Heger [mailto:oliver.heger@oliver-heger.de]
>>> Sent: Sunday, September 18, 2016 06:37
>>> To: Commons Developers List <de...@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\u2019ve been following the thread for some time here, and was looking
> for a place to jump in. Dennis\u2019 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][VOTE][RC2] Release "Apache Commons RNG" version 1.0
Posted by Rob Tompkins <ch...@gmail.com>.
> On Sep 18, 2016, at 12:20 PM, Dennis E. Hamilton <de...@acm.org> wrote:
>
>
>
>> -----Original Message-----
>> From: Oliver Heger [mailto:oliver.heger@oliver-heger.de]
>> Sent: Sunday, September 18, 2016 06:37
>> To: Commons Developers List <de...@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?
-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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org