river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: River 3.0 beta release candidate
Date Tue, 17 Dec 2013 15:14:35 GMT

Assuming that there aren’t major incompatibilities, I think that would be a “minor”
version change according to our versioning policy, so we’d be looking at the “2.3” branch
rather than a “3.0” release.

I’m still unnerved by the massive amounts of changes to both code and tests in the qa_refactor
branch, as well as the apparent instability of the code, although that seems to be improving.
 In the next few weeks I’m going to try and setup a cross-test case, to see what the “2.2”
tests say about the potential “2.3” release and vice-versa.

I think what I’d really like to see is an incremental approach where we update limited components
of the “2.2” branch, one at a time.  Is there anything that we could pull out piecemeal?
 Maybe it would make sense to split out the infrastructure services, like Reggie, Mahalo,
and Outrigger into different sub-projects that could be updated separately?  

Any thoughts?


On Dec 17, 2013, at 5:03 AM, Peter <jini@zeus.net.au> wrote:

> When the qa_refactor branch stabilises, I plan to merge trunk and provide a beta release
for client compatibility testing.
> Changes made have been focused on making our code thread safe, there are significant
changes internally, the public api remains focused on backward compatibility, however it is
advisable that client services adopt new safe construction techniques for services and implement
the new Commission interface.
> What's a suitable test period for client testing?
> Regards,
> Peter.

View raw message