I'm happy to accept whatever release version number that the committers decide when that time comes.
I think it best to narrow our focus for now on how to proceed with the release process. Regards, Peter. ----- Original message ----- > > The way that services are instantiated and setup is an implementation > detail. When I think of compatibility I think of the API and the lookup > methods. We think of compatibility from a client point of view. From > the client point of view, using a service looks like this: > > - Use multicast of unicast discovery to find one or more > ServiceRegistrar instances - Call lookup(…) on one or more of these > instances to get a set of service candidates - Choose a candidate and > prepare() it using a ProxyPreparer, to yield a usable service proxy. - > Make calls on it. Ideally hang on to this proxy instance, so you can > skip the discovery and lookup next time you need it. - If the call > fails, repeat the lookup (and possibly discovery) til you get a proxy > that works. > > Nowhere does the client need to know whether the service instance is > started up using the “com.sun.jini.start” mechanism, your Commission > interface, some other IOC container (Rio, Harvester, Seven or > RiverContainer) or some unknown mechanism that starts with a static > main() method. > > JSK2.0 was 2.0 because of the introduction of the proxy verification > mechanisms, as well as JERI. Absent some new client usage mechanism, > River doesn’t need to go to 3.0. > > Cheers, > > Greg. > > > > On Dec 17, 2013, at 1:58 PM, Peter <j...@zeus.net.au> wrote: > > > 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. > > > > > >
