On 06/13/2016 03:12 PM, Stephen Kelly wrote: > 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.
Yes. We don't want to end up like we did with policies where there is no plan or schedule for removal. We are carrying along quite a bit of code (and complexity) only to support policy OLD behavior. On 06/11/2016 04:32 PM, Tobias Hunger wrote: > Using the CMake version as protocol version is really painful on the other > hand: Yes. The protocol should have its own versioning. IIRC the earlier discussion that proposed using the CMake version was back when we were going to put all this in a .json file on disk during generation. For an interactive protocol session it makes much more sense to have a dedicated protocol versioning scheme. -Brad -- 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
