Tobias Hunger wrote: >> * Designing a protocol like this is hard (and not fast) > > We have been discussing this for about two years now.
That's a misleading thing to say. Time since an effort or discussion started has never been a guideline for when something is ready for CMake master. > I see no problem there: You can always cut out old protocols if their > implementation hurts too much. That sucks for users that need the old > version, but it can be cleanly detected. I think you underestimate the cost of supporting old versions and the benefit of exploring the design space to get it as right as possible the first time (exploring the design space isn't the same as giving IDE developers votes). I suggest switching gears and designing the initial protocol handshake and version negotiation, and come back to this buildsystem description part of the protocol later. Designing the how versioning the protocol works can include design and discussion of end of support for particular protocol versions (how many years/releases it will be deprecated for before being removed etc). That is the first part that would get merged to master anyway. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
