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 19:16:51 GMT
On Sat, Dec 28, 2013 at 1:30 PM, Phil Steitz <phil.steitz@gmail.com> wrote:

> 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?
>

I am not going to take the time right to put on my software archeologist
hat and find a specific example in our programs but we do have a larger
application server that depends on the large Apache code bases of Active MQ
and CXF (and their dependencies) in addition to Eclipse Jetty and a pile of
Commons components. Because all of these code bases do NOT by policy, or
even if by policy, reliably, change package names when they break BC, it
can be a hackathon when we need to update dependencies. No BC breakage is
one less hurdle to move the stack along.  Yes, of course, we then have to
deal with semantic changes, but avoiding both compile-time and runtime
surprise is always a good thing. So whenever I see I BC break without a
package change, I have to wonder what trouble lies ahead. If there is a
package name change, then I have to take conscious action to use the new
version by changing imports in my app, which also does not break 3rd party
code.

Gary


> 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
>
>


-- 
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