Coordinating Parameter 'master' merging for dependent libraries
I intend to merge Parameter 'develop' to 'master' for the next release of Boost. Cromwell Enage has done a great job of adding modern improvements to the Parameter library via PRs, while maintaining full backward compatibility with the Parameter public interface. I have reviewed and approved those changes and, where I have been lax, Peter Dimov has pointed out weaknesses in some of those changes, which Cromwell has corrected. The changes which Cromwell has made have also involved improvements in the Parameter private interface(s), which have entailed some updates to the 'develop' branch of some Boost libraries which unfortunately depended on some aspects of the Parameter private interface. These updates have already been made in those other library's 'develop' branch. At this point any further possible changes for Parameter for a while will very likely be in the Parameter documentation, which requires no syncing with other libraries, so this is an excellent time for merging. Since the merging for other libraries dependent on Parameter must be synced to the merging of Parameter from 'develop' to 'master' what is the best way to go about this ? Obviously I have first to merge Cromwell's changes from 'develop' to 'master', which is easily done. How should I inform other libraries that they need to merge their Parameter dependent 'develop' changes to 'master' ? Should I create PRs for doing this ? We do not normally create PRs for the 'master' branch of any Boost library. Should I create Issues for those other libraries and hope the maintainers of the other libraries will take the appropriate action ? Or should I inform the maintainers of the other libraries in this thread, and prompt them to review their changes here to get them to merge them from 'develop' to 'master' ? The other libraries involved are: Accumulators, Log, Convert, Lockfree, Signals2, and Graph. Cromwell knows more about the specific 'develop' changes in those libraries which need to be merged to 'master' than I do, since he was instrumental in creating the PRs that would allow these libraries to work with the updated Parameters' internals, so he may chime in here, but I would like to get this done so that Parameter and its dependent Boost libraries get properly updated for the next Boost release. Of course I will also plan with Cromwell update notes for Parameter to be part of the next release.
On 2/2/19 1:16 AM, Edward Diener via Boost wrote:
Since the merging for other libraries dependent on Parameter must be synced to the merging of Parameter from 'develop' to 'master' what is the best way to go about this ? Obviously I have first to merge Cromwell's changes from 'develop' to 'master', which is easily done. How should I inform other libraries that they need to merge their Parameter dependent 'develop' changes to 'master' ? Should I create PRs for doing this ? We do not normally create PRs for the 'master' branch of any Boost library. Should I create Issues for those other libraries and hope the maintainers of the other libraries will take the appropriate action ? Or should I inform the maintainers of the other libraries in this thread, and prompt them to review their changes here to get them to merge them from 'develop' to 'master' ?
I did create "Merge develop to master" kind of PRs for some libraries. I'm not sure how convenient it is for other library maintainers, but even if they prefer to merge themselves, the PR can simply serve as a reminder, the same way a ticket does. There's no obligation to actually merge that PR.
The other libraries involved are: Accumulators, Log, Convert, Lockfree, Signals2, and Graph.
Boost.Log is already merged. Its develop and master are the same and are compatible with both Boost.Parameter develop and master.
On 2/2/19 1:16 AM, Edward Diener via Boost wrote:
The other libraries involved are: Accumulators, Log, Convert, Lockfree, Signals2, and Graph.
The 'develop' branches of Boost.Accumulators, Boost.Convert, Boost.Lockfree, and Boost.Signals2 rely solely on the public interface of the 'develop' branch of Boost.Parameter. Only Boost.Graph remains deviant in that regard, but since that access is encapsulated by bgl_named_params, at this point I'm more concerned with upgrading Boost.Graph algorithms via Boost.Parameter's code generation macros, which provide modern alternatives to bgl_named_params. However, I'll need PR #73 reviewed for acceptance to Boost.Parameter before I can start submitting PRs to Boost.Graph in that direction. Nevertheless, I'm willing to wait until after the merging to master is complete or even until after 1.70 is released. Cromwell D. Enage
participants (3)
-
Andrey Semashev
-
Cromwell Enage
-
Edward Diener