[release] 1.69.0 deadline for new libraries approaching
It's that time again! On Wednesday, the master branch will be closed for adding new libraries. Upcoming dates: * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes * 31-Oct: Boost 1.69.0 closed for major code changes * 7-Nov: Boost 1.69.0 closed for beta * 14-Nov: Boost 1.69.0 beta 1 * 5-Dec: Boost 1.69.0 closed for release * 12-Dec: Boost 1.69.0 release -- The Boost Release Team
On 22/10/2018 18:19, Peter Dimov via Boost wrote:
Marshall Clow wrote:
* 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes
OK... do we want CMake config files installed by 1.69 or not, then?
I assume as pure additions they're not really breaking changes? In any case it's going to be a pain to avoid merging those specific files to master over multiple repros. Best, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 10/22/18 10:19 AM, Peter Dimov via Boost wrote:
Marshall Clow wrote:
* 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes
OK... do we want CMake config files installed by 1.69 or not, then?
I'd like to know this as well. If so, I presume that we can consider the Boost/CMake issues resolved and we can just move on from this? Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2018-10-22 02:39 PM, Robert Ramey via Boost wrote:
On 10/22/18 10:19 AM, Peter Dimov via Boost wrote:
Marshall Clow wrote:
* 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes
OK... do we want CMake config files installed by 1.69 or not, then?
I'd like to know this as well. If so, I presume that we can consider the Boost/CMake issues resolved and we can just move on from this?
What issues do you think are resolved ? As far as I understand, the current endeavor is to auto-generate config files to make it easier to consume (individual) Boost libraries in CMake projects. That's entirely orthogonal to the question of whether and how Boost libraries switch to CMake. So, as far as I'm concerned, your effort to agree on a Request For Proposals is still very much relevant. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 10/22/18 11:45 AM, Stefan Seefeld via Boost wrote:
OK... do we want CMake config files installed by 1.69 or not, then?
I'd like to know this as well. If so, I presume that we can consider the Boost/CMake issues resolved and we can just move on from this?
What issues do you think are resolved ? As far as I understand, the current endeavor is to auto-generate config files to make it easier to consume (individual) Boost libraries in CMake projects. That's entirely orthogonal to the question of whether and how Boost libraries switch to CMake.
So, as far as I'm concerned, your effort to agree on a Request For Proposals is still very much relevant.
The reason I ask is that working to implement something presumes that there's consensus on what should be implemented. I don't want to find myself in the position of committing serious effort to a task which has been eclipsed by events. Historically, Boost Tooling has been developed in just this way. Someone with access just implements something and drops on the rest of us. I think that this practice is one of the reasons that we've been frustrated with boost tooling in general. My proposal is/was an attempt to break this cycle by approaching from a different angle - inspired by Boosts success in other aspects - motivating the creating of quality C++ libraries. Robert Ramey
Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2018-10-22 03:08 PM, Robert Ramey via Boost wrote:
On 10/22/18 11:45 AM, Stefan Seefeld via Boost wrote:
OK... do we want CMake config files installed by 1.69 or not, then?
I'd like to know this as well. If so, I presume that we can consider the Boost/CMake issues resolved and we can just move on from this?
What issues do you think are resolved ? As far as I understand, the current endeavor is to auto-generate config files to make it easier to consume (individual) Boost libraries in CMake projects. That's entirely orthogonal to the question of whether and how Boost libraries switch to CMake.
So, as far as I'm concerned, your effort to agree on a Request For Proposals is still very much relevant.
The reason I ask is that working to implement something presumes that there's consensus on what should be implemented. I don't want to find myself in the position of committing serious effort to a task which has been eclipsed by events.
Historically, Boost Tooling has been developed in just this way. Someone with access just implements something and drops on the rest of us. I think that this practice is one of the reasons that we've been frustrated with boost tooling in general.
I understand, and agree. In fact, my main argument against the "wholesale move to CMake" is precisely that we (the maintainers) are left to deal with users who will expect support when something doesn't quite work the way *they* expect. So even if the initial infrastructure generation is done by someone else (or is automated entirely), this still has an impact on the projects' maintenance. In that sense I think the inclusion of those config files, or at least, any "official support" that may come with it (implied or not), is something that needs to be agreed upon. And *that* would definitely be part of your RFP. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 10/22/18 12:25 PM, Stefan Seefeld via Boost wrote:
On 2018-10-22 03:08 PM, Robert Ramey via Boost wrote:
In that sense I think the inclusion of those config files, or at least, any "official support" that may come with it (implied or not), is something that needs to be agreed upon. And *that* would definitely be part of your RFP.
The Draft RFP has received only modest criticism. Some minor issues with wording and reservations about the proposal for anonymity of submitters. I'm highly doubtful that this is due to universal agreement that this is path we want go down. I'm concerned that this is a sign of lack of interest. I don't want to embark upon this unless its pretty strong support from the boost community. If there's isn't sufficient support of such an effort now, wwe can always wait another year. Robert Ramey
Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
On 10/22/18 10:19 AM, Peter Dimov via Boost wrote:
Marshall Clow wrote:
* 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes
OK... do we want CMake config files installed by 1.69 or not, then?
I'd like to know this as well. If so, I presume that we can consider the Boost/CMake issues resolved and we can just move on from this?
I doubt it. The CMake issue is much bigger than this.
Marshall Clow via Boost-users
It's that time again!
On Wednesday, the master branch will be closed for adding new libraries.
Upcoming dates: * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes * 31-Oct: Boost 1.69.0 closed for major code changes * 7-Nov: Boost 1.69.0 closed for beta * 14-Nov: Boost 1.69.0 beta 1 * 5-Dec: Boost 1.69.0 closed for release * 12-Dec: Boost 1.69.0 release
Is https://github.com/boostorg/heap/issues/12 a blocker for Beta 1? It doesn't seem to break tests but breaks ~4 real consumers.
It's that time again!
On Wednesday, the master branch will be closed for adding new libraries.
Upcoming dates: * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes * 31-Oct: Boost 1.69.0 closed for major code changes * 7-Nov: Boost 1.69.0 closed for beta * 14-Nov: Boost 1.69.0 beta 1 * 5-Dec: Boost 1.69.0 closed for release * 12-Dec: Boost 1.69.0 release
Make sure the current graph-devel branch makes it in. There are a lot of stability improvements over there.
participants (7)
-
Jan Beich -
John Maddock -
jrmarsha -
Marshall Clow -
Peter Dimov -
Robert Ramey -
Stefan Seefeld