river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: River 3.0 beta release candidate
Date Tue, 17 Dec 2013 18:58:21 GMT
I think changing services to use safe construction techniques is enough to cause the version

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.



----- 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 <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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message