There is little total value in doing anything to the non qa_refactor code. It is what it is, and should just be left as it is for use of anyone who might still want to use it for some odd reason.
It would be best to just spend the effort on making qa_refactor into the 3.0.0 release. Peter has stated that there are no compatibility issues with the code in qa_refactor. He understand the API/source as well as the binary compatibility issue, and the binary compatibility is the larger issue for “evaluating” this codebase in any existing environment. The suggestion for use a compatibility layer for the rename takes care of that issue. That just leaves it up to the community to jump in and do testing. I would strongly suggest that community testing should operate off of the existing testing infrastructure, and we would want to extend those tests with anything that we believe our own software might depend on working appropriately so that others can help with that testing, as well as having such dependencies documented in the test suite that will help keep that compatibility in place for the future. Gregg On May 14, 2014, at 9:04 AM, Rafał Krupiński <rafal.krupin...@sorcersoft.com> wrote: > Dnia środa, 14 maja 2014 06:26:26 Bryan Thompson pisze: >> What is the argument for pushing out the qa_refactor based release? Do you >> believe that it is not ready to evaluate in production systems? Or do you >> believe that the rename is more important? If so, why? Just curious about >> people's perspectives here. > > These changes (build and rename) can be made to current branch. It will be > easier to find any problems with the migration, if any. > > Regards > Rafał
