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ł
