commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [VOTE] Release [pool] 2.1 based on RC2
Date Sat, 28 Dec 2013 16:07:46 GMT
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. 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
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message