On Wed, Nov 20, 2013 at 3:22 PM, Thomas Neidhart <thomas.neidh...@gmail.com>wrote:
> 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 ;-(. > Good call Thomas ;) I'm happy to review another RC. Gary > > Thanks, > > Thomas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@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
