We can't afford to hold up 2.3.0 much longer, the 2.2.0 release has numerous synchronization bugs, these will become more apparent on multicore hardware. The longer we wait the more likely they'll present in deployed systems.
The latest branch is in skunk/qa-refactoring, I encourage anyone to jump in and help. We're currently investigating replacing TaskManager. This branch passes all TCK tests, we just need to fix remaining synchronization issues. Because changes have a ripple effect, one fix will expose other bugs because execution paths change. It's probably better that we fix these issues while the build is monolithic, otherwise there are more possible combinations that would require additional integration testing. I proposed a modular build 2 years ago, but developers were divided over it at that time. I've fixed all the findbugs issues, has anyone used JPF? I'm going to try this after we've fixed TaskManager. Regards, Peter. ----- Original message ----- > Notes on the commit I just did -- Holy Macinaw, there's been a lot of > changes checked in since our last release (2.2.0). Enough to make me a > little nervous about 2.3 - Ideally we would release in a much more > incremental fashion to reduce risk. In fact I wonder if we ought to > talk about modularising some of the later changes so that use of the new > code is optional, or perhaps planning a series of point-releases. > > In any case, on the 2.2 branch I applied the fix for RIVER-149 plus some > documentation updates. The changes after that seem to be related to the > concurrency items that are currently being worked on in the trunk. I'm > currently running the test suite locally. Depending on the results > we'll see about rolling release 2.2.1. > > Cheers, > > Greg. >
