[system][asio] Breaking changes procedure?
At the suggestion of Emil Dotchevski, seconded by Chris Kohlhoff, on my trunk working copy I've moved the system-specific portions of the header <boost/system/error_code.hpp> into new headers. They are named: <boost/system/cygwin_error.hpp> <boost/system/linux_error.hpp> <boost/system/windows_error.hpp> This is a breaking change for asio, and any other boost code that depends on <boost/system/error_code.hpp> containing system-specific enums. New #includes are required for whichever headers apply. This isn't a disruptive change (because the effects are very localized), and normally I'd just coordinate it offline with Chris. But I'd like to shakedown the procedure that should be followed for disruptive breaking changes. Thus this posting to give others a chance to comment. I think the procedure for such breaking changes should be something like: * Create a branch, branches/system. The contents are the entire boost tree. * Apply the Boost.System changes to that branch. * Announce the branch on the list, and encourage any developers affected to update their libraries on the branch. * Once all affected libraries are changed on the branch and passing tests on developer's machines, merge the changes into a working copy of the trunk and do a single commit. * Watch regression tests closely to be sure nothing else broke. Does this sound right? --Beman
Beman Dawes wrote:
At the suggestion of Emil Dotchevski, seconded by Chris Kohlhoff, on my trunk working copy I've moved the system-specific portions of the header <boost/system/error_code.hpp> into new headers. They are named:
<boost/system/cygwin_error.hpp> <boost/system/linux_error.hpp> <boost/system/windows_error.hpp>
This is a breaking change for asio, and any other boost code that depends on <boost/system/error_code.hpp> containing system-specific enums. New #includes are required for whichever headers apply.
This isn't a disruptive change (because the effects are very localized), and normally I'd just coordinate it offline with Chris. But I'd like to shakedown the procedure that should be followed for disruptive breaking changes. Thus this posting to give others a chance to comment.
I think the procedure for such breaking changes should be something like:
* Create a branch, branches/system. The contents are the entire boost tree.
* Apply the Boost.System changes to that branch.
* Announce the branch on the list, and encourage any developers affected to update their libraries on the branch.
* Once all affected libraries are changed on the branch and passing tests on developer's machines, merge the changes into a working copy of the trunk and do a single commit.
* Watch regression tests closely to be sure nothing else broke.
Does this sound right?
I'd add: * Try to fix all affected dependent boost libraries, if possible. Before: * Announce the branch on the list, and encourage any developers affected to update their libraries on the branch. This is how I did it with the recent fusion tweaks. I also recall that the MPL author(s) also graciously tweaked all dependent libraries when they changed apply_if to eval_if. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Beman Dawes wrote:
...
I think the procedure for such breaking changes should be something like:
* Create a branch, branches/system. The contents are the entire boost tree.
* Apply the Boost.System changes to that branch.
* Announce the branch on the list, and encourage any developers affected to update their libraries on the branch.
* Once all affected libraries are changed on the branch and passing tests on developer's machines, merge the changes into a working copy of the trunk and do a single commit.
* Watch regression tests closely to be sure nothing else broke.
Does this sound right?
I'd add:
* Try to fix all affected dependent boost libraries, if possible.
Before:
* Announce the branch on the list, and encourage any developers affected to update their libraries on the branch.
Yep, that makes sense.
This is how I did it with the recent fusion tweaks. I also recall that the MPL author(s) also graciously tweaked all dependent libraries when they changed apply_if to eval_if.
I'm under the impression Chris may maintain asio files elsewhere, so asio may be a special case. Chris? --Beman
Beman Dawes wrote:
I'm under the impression Chris may maintain asio files elsewhere, so asio may be a special case. Chris?
Yes, that's the case. However, with respect to the specific changes to boost.system proposed here, I don't expect that any boost.asio changes are required as the OS-specific enums themselves are not used in the asio source code. I reckon you can just go ahead and make the changes and, if the asio tests pass (as expected) commit straight to the trunk. (Unless you really want to try out the branch procedure, of course.) Cheers, Chris
participants (3)
-
Beman Dawes -
Christopher Kohlhoff -
Joel de Guzman