----- 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.
It's possible to test qa_refactor with 2.2 but not the other way around without copying libs. I'd expect numerous test failures due to missing permissions and at least some test failures caused by visibility synchronization bugs. I'm interested to see the outcome and appreciate your efforts. > > 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? It would be a huge amount of work, but it is possible, so considering it for a moment: The most important change is safe construction, it alone requires sweeping changes. I'd do that first, but it will require a significant effort to not include other changes and to only change what was necessary for safe construction. The next would be backporting the fixes for sync bugs in Jeri. There would be numerous incremental changes after that and we're probably looking at a two to three year release process with progress otherwise stalled. It's worth remembering I've been working on this codebase already now for about 4 years. My main concern is though, we'd need to accept test failures in these releases, because we'd have to resist adding fixes to address the failures or it'd be a case of where do we stop. Which is exactly what got me to the situation today. I think it woud be important to have a released beta build with all changes while the backporting process was underway, so changes weren't missed, but it's likely the beta release would stabilise much earlier than the main release branch. I'd prefer to have a 6 month beta release evaluation period, so people can try out the code and identify issues. We could release parallel 2.2 and 3.0 branches, during an extended evaluation period, this would be a lot less work than incremental backport releases. Java 8 has significant changes in comparison to 7 and we did inherit a similar monolithic build process, so it seems to make sense to me at least that the correct approach is to allow an evaluation period. Is it possible for animal sniffer to analyse the public api? Regards, Peter. 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. >
