I think changing services to use safe construction techniques is enough to cause the version jump.
At this point I've allowed services to continue unsafe construction practices, while logging a SEVERE warning when the Commission interface isn't implemented, rather than fail. This is a fundamental change to the way services are written. Regards, Peter. ----- Original message ----- > > 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. >
