Works for me. Has compatibility, concurrency bug fixes, and performance gains,
Bryan > On May 14, 2014, at 6:58 AM, Michał Kłeczek <[email protected]> wrote: > > That is going to cause qa_refactor merge difficult. > > My take - pretty radical - on this would be: > > 1. Rename branch trunk to "2.x.x" > - 2.x would enter "legacy maintanance" mode > 2. Rename qa_refactor to "trunk" > 3. Rename packages in "trunk", introduce compatibility jars > 4. Release 3.0.0-alpha from "trunk" > 4.a test test test chase bugs :) > 5. Depending on how the community feels modular (mavenized) build is > important > - modify "trunk" before final 3.0.0 release (this can be postponed until > after > 3.0.0) > 6. Release 3.0.0 from trunk > > The problem right now is that it is unclear what branch should be a base for > any work that potentially is going to be included in 3.x.x - is it > qa_refactor > or is it trunk? > So we need an official 3.x.x branch ASAP. > > I really think work done in qa_refactor is important enough to make it the > main development branch. The community seems to agree that sooner or later it > _will_ be merged. > > Regards, > Michal > >> On Wednesday 14 of May 2014 11:52:32 Rafał Krupiński wrote: >> Dnia środa, 14 maja 2014 18:50:28 Peter Firmstone pisze: >>> Perhaps we should postpone the rename for now. >> >> Actually, 3.0 is the only moment to change the names of classes, as it >> breaks compatibility and strongly suggests new major version number. >> >> May I suggest another approach to the roadmap: >> >> Release +1 - modularized build, no code change - full binary compatibility. >> >> Release +2 - change the namespaces and class names, if any. Introduce >> compatibility jars. >> >> Release +3 - merge/replace with the qa_refactor. >> >> Regards >> Rafał >
