You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2013/12/24 21:37:39 UTC
[CANCELLED][VOTE] Release [pool] 2.1 based on RC1
The clirr breakage needs to dealt with / explained in the release
notes. As it stands, the statements about compatibility are not
correct.
I think the breakage is OK, but would appreciate suggestions on how
to document in the release notes.
Phil
On 12/23/13, 9:21 PM, Phil Steitz wrote:
> Pool 2.1 RC1 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-019/
>
> Details of changes since 1.6 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_RC1/
>
> Site:
> http://people.apache.org/~psteitz/pool/pool-2.1-rc1/ <http://people.apache.org/%7Epsteitz/pool/pool-2.1-rc1/>
> (Broken links to Javadoc versions expected)
>
> Clirr Report:
> http://people.apache.org/~psteitz/pool/pool-2.1-rc1/clirr-report.html <http://people.apache.org/%7Epsteitz/pool/pool-2.1-rc1/clirr-report.html>
>
> RAT:
> http://people.apache.org/~psteitz/pool/pool-2.1-rc1/rat-report.html <http://people.apache.org/%7Epsteitz/pool/pool-2.1-rc1/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
Re: [CANCELLED][VOTE] Release [pool] 2.1 based on RC1
Posted by Phil Steitz <ph...@gmail.com>.
On 12/26/13, 1:31 AM, Mark Thomas wrote:
> On 24/12/2013 20:37, Phil Steitz wrote:
>> The clirr breakage needs to dealt with / explained in the release
>> notes. As it stands, the statements about compatibility are not
>> correct.
> I would argue that there is nothing incorrect about those statements. No
> client of Pool should be using any (.*)MXBean class directly since the
> sole purpose of such a class is to expose $1 via JMX.
Agreed in principle. The only issue would be if someone decided to
implement their own PooledObject implementation, not extending
DefaultPooledObject but reusing the management interface. I know
this is far-fetched. Technically, since the interface is public, we
have broken compatibility, so I would like to either remove the
claim of source/binary compat or qualify it in some way. I will fix
this.
>
>> I think the breakage is OK, but would appreciate suggestions on how
>> to document in the release notes.
> I don't think anything belongs in the release notes about this. The
> MXBean naming convention should be familiar to anyone using Pool. If it
> is felt that something more needs to be done then I'd suggest adding an
> explicit warning to all the MXBean classes that they must not be used
> directly by clients
or reused by extensions of pool classes
> and that they may change in compatible ways between
> any release including point releases.
Will do.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [CANCELLED][VOTE] Release [pool] 2.1 based on RC1
Posted by Mark Thomas <ma...@apache.org>.
On 24/12/2013 20:37, Phil Steitz wrote:
> The clirr breakage needs to dealt with / explained in the release
> notes. As it stands, the statements about compatibility are not
> correct.
I would argue that there is nothing incorrect about those statements. No
client of Pool should be using any (.*)MXBean class directly since the
sole purpose of such a class is to expose $1 via JMX.
> I think the breakage is OK, but would appreciate suggestions on how
> to document in the release notes.
I don't think anything belongs in the release notes about this. The
MXBean naming convention should be familiar to anyone using Pool. If it
is felt that something more needs to be done then I'd suggest adding an
explicit warning to all the MXBean classes that they must not be used
directly by clients and that they may change in compatible ways between
any release including point releases.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org