commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <thomas.neidh...@gmail.com>
Subject [CANCELLED][VOTE] Release of Commons Collections 4.0 based on RC4
Date Wed, 20 Nov 2013 20:22:19 GMT
On 11/17/2013 08:22 PM, Thomas Neidhart wrote:
> Hi,
> 
> I'd like to call a vote for releasing Commons Collections 4.0 based on
> RC4 and I am quite confident with this RC after all the valuable
> feedback from the previous RCs has been integrated.
> 
>  Changes since RC3:
> 
>   * [COLLECTIONS-501] Renamed methods "V MultiKeyMap#remove(Object,
>     Object, ...)" to "V MultiKeyMap#removeMultiKey(Object, Object,
>     ...)" to avoid future conflicts with a default method of the Map
>     interface in Java 8.
>   * [COLLECTIONS-500] Renamed "V MultiMap#remove(K, V)" to "boolean
>     MultiMap#removeMapping(K, V)" to avoid future conflicts with a
>     default method of the Map interface in Java 8.
>   * fixed compilation problem with IBM JDK 5
>   * fixed test failures with IBM JDK 6 by disabling some of them in
>     case the tests are executed with such a JDK
>   * added note to the release notes (textual version) wrt disabled tests
> 
>  Changes since RC2:
> 
>   * [COLLECTIONS-499] Refactored the test framework for Bag
>     implementations to extend from "AbstractCollectionTest" by
>     decorating the concrete Bag instance with a CollectionBag or
>     CollectionSortedBag.
>   * [COLLECTIONS-498] "CollectionBag" will now also respect the
>     contract of the decorated bag in case a null argument is provided
>     to either removeAll or retainAll.
>   * [COLLECTIONS-497] Added bag decorator "CollectionSortedBag" which
>     decorates a SortedBag to make it comply with the Collection
>     contract.
>   * [COLLECTIONS-496] "UnmodifiableBoundedCollection" does now also
>     implement the marker interface "Unmodifiable" similar as all other
>     unmodifiable decorators.
>   * [COLLECTIONS-495] "UnmodifiableTrie#unmodifiableTrie(Trie)" will
>     not decorate again an already unmodifiable Trie. Also the return
>     type has been changed to "Trie" to be consistent with other
>     Unmodifiable decorators.
>   * [COLLECTIONS-494] Moved "Equator" interface to base package for
>     consistency. Thanks to Emmanuel Bourg.
>   * improved release notes with suggestions from Emmanuel Bourg
>   * added unit tests for TrieUtils and QueueUtils and factory methods
>     for all Unmodifiable decorators
>   * added more unit tests for the Queue interface
>   * cleanup of many test classes: removed unused imports, unneeded
>     constructors
> 
>  Changes since RC1:
> 
>   * release notes are now also included in the binary distribution
>   * removed spurious hashCode() method in AbstractPatriciaTrie, the
>     inherited one from AbstractMap will be used instead
> 
> 
>   Collections 4.0 RC4 is available for review here:
>     https://dist.apache.org/repos/dist/dev/commons/collections/
>     (svn revision 3546)
> 
>   Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-148/org/apache/commons/commons-collections4/4.0/
> 
>   The tag is here:
> 
> https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_4_0_RC4/
>     (svn revision 1542797)
> 
>   Site:
>     http://people.apache.org/builds/commons/collections/4.0/RC4/
> 
>   Details of changes can be found in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt
> http://people.apache.org/builds/commons/collections/4.0/RC4/changes-report.html
> 
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Note: the clirr report is generated against 4.0-alpha1 and it is also
> highlighted in the release notes that this release is not compatible
> with any previous release.
> 
> Thank you for your reviews,

Hi all,

thanks to all people taking the time to review and test this RC, but
unfortunately, I have to cancel the vote.

Emmanuel has discovered a flaw in the FalsePredicate where the public
singleton instance is typed in a way that makes it very inconvenient to use.

At first I thought this can be mitigated for this release and fixed in
the next point release, but after looking through the whole codebase, I
have discovered lots of these patterns. Almost all utils have such
singleton instances and also some other functor related classes.

Imho, it is better to cut another RC to fix these issues and I hope
everybody is still willing to vote another time ;-(.

Thanks,

Thomas

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


Mime
View raw message