commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [VOTE] Release [pool] 2.1 based on RC2
Date Sat, 28 Dec 2013 18:30:39 GMT
On 12/28/13, 8:07 AM, Gary Gregory wrote:
> On Fri, Dec 27, 2013 at 10:15 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
>
>> On 12/27/13, 2:09 PM, Gary Gregory wrote:
>>> I have to say that the 'fix' for the Clirr issue is underwhelming, it
>> does
>>> not exist IMO.
>>>
>>> - The new API does not have a @since 2.1 in the Javadoc.
>> Should be fixed, but not a blocker, IMO.
>>> - There is nothing on the site that addresses the Clirr error and why it
>> is
>>> OK to have.
>>> - The release notes do not talk about the Clirr error as well.
>> People reading the site and/or release notes have limited time, like
>> the rest of us.  Anyone actually looking at the Clirr report will
>> get immediately that a method was added to an Mbean interface - no
>> consequence to them.
>
> That might be true for simple projects that only have one layer of
> dependencies that I control. In larger projects though, when more than one
> jar depends on [pool], that will not be the case. 

Can you provide a real example where the "breakage" in question
could make a difference to any application at any layer of anyone's
stack? 

Phil

> This is when I want to
> know that [pool] is BC or not, if it is not (like 2.1) I run the risk of
> blowing up the app because I am not the only one using [pool]. 
> If I see a
> red Clirr that is NOT documented, it looks either like an omission
> (relatively safe but undocumented) or a bug (the change should not have
> been made). If the red Clirr report is not documented, I, as a user am left
> in the dark. Why would we want to leave users in the dark? It does not
> matter that the change is too a Foo or a Bar kind of interface because I am
> not the only one using pool. If it is documented, then it's a better for
> all. I'd be OK with this if the site is updated after the release, even
> though it's a mess to have -SNAPSHOT sites (a different topic).
>
> Gary
>
>
>
>
>> Why distract readers of release notes who are
>> scanning for things relevant to them with what amounts to a
>> non-issue?  Similar for web site doco. Needless distraction, IMO,
>> unless someone wants to step up to author a full section on JMX
>> instrumentation, which would be valuable / substantive and could
>> include disclaimers on interfaces.  Again, this is not a release
>> blocker, IMO.  I would rather proceed with the release and welcome
>> contributions to the web site from any / all who want to help with it.
>>
>> Phil
>>> I can't bring myself to -1 this since the software is not broken, but the
>>> documentation feels broken to me.
>>>
>>> Gary
>>>
>>>
>>> On Thu, Dec 26, 2013 at 8:18 PM, Phil Steitz <phil.steitz@gmail.com>
>> wrote:
>>>> I have updated the release notes and MBean interface class javadoc to
>>>> address feedback from RC1.
>>>>
>>>> Pool 2.1 RC2 is available for review here:
>>>>   https://dist.apache.org/repos/dist/dev/commons/pool/
>>>>
>>>> Maven artifacts are here:
>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-022/
>>>> Details of changes since 2.0 are in the release notes:
>>>>   https://dist.apache.org/repos/dist/dev/commons/pool/RELEASE-NOTES.txt
>>>>
>>>> The tag is here:
>>>>    <
>> http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_2_1_RC2/
>>>>> http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_2_1_RC2/
>>>> Site:
>>>>   http://people.apache.org/~psteitz/pool/pool-2.1-rc2/
>>>>   (Broken links to Javadoc versions expected)
>>>>
>>>> Clirr Report:
>>>>   http://people.apache.org/~psteitz/pool/pool-2.1-rc2/clirr-report.html
>>>>
>>>> RAT:
>>>>   http://people.apache.org/~psteitz/pool/pool-2.1-rc2/rat-report.html
>>>>
>>>>   Please review the release candidate and vote.
>>>>   This vote will close no sooner that 72 hours from now
>>>>
>>>>   [ ] +1 Release these artifacts
>>>>   [ ] +0 OK, but...
>>>>   [ ] -0 OK, but really should fix...
>>>>   [ ] -1 I oppose this release because...
>>>>
>>>> Thanks!
>>>>
>>>> Phil
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>


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


Mime
View raw message