On 12/28/13, 8:07 AM, Gary Gregory wrote: > On Fri, Dec 27, 2013 at 10:15 PM, Phil Steitz <phil.ste...@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.ste...@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-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
