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? Greg. On Dec 17, 2013, at 5:03 AM, Peter <j...@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.
