Boost.Signals deprecation and removal
This first implementation of signals has been deprecated since the 1.54 release. (When) are we going to remove it? It is under management of the CMT, and it has been deprecated for over 10 major releases. I would like to suggest we remove it in the Boost 1.68.0 release. - Jim
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of James E. King, III via Boost Sent: 27 May 2018 19:22 To: boost@lists.boost.org Cc: James E. King, III Subject: [boost] Boost.Signals deprecation and removal
This first implementation of signals has been deprecated since the 1.54 release. (When) are we going to remove it? It is under management of the CMT, and it has been deprecated for over 10 major releases. I would like to suggest we remove it in the Boost 1.68.0 release.
This is probably overdue, but I think I recall a consensus for a 'warning - notification of removal' at least one release before it happens. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
This first implementation of signals has been deprecated since the 1.54 release. (When) are we going to remove it? It is under management of the CMT, and it has been deprecated for over 10 major releases. I would like to suggest we remove it in the Boost 1.68.0 release.
i had been working on one project, that was never migrated from signals to signals2, as attempts to migrate miserably failed: compile times significantly increased and the msvc linker would run out of memory. this project is currently migrated away from boost.signals (1 and 2) to a more lightweight solution (nod signals), but i can imagine that there are some projects out there which still use signals(1) and which would run into trouble when it will be removed completely. otoh i wonder if signals1 causes much maintenance overhead, that justifies potentially breaking downstream code
On Tue, May 29, 2018 at 11:11 PM, Tim Blechmann via Boost < boost@lists.boost.org> wrote:
This first implementation of signals has been deprecated since the 1.54 release. (When) are we going to remove it? It is under management of the CMT, and it has been deprecated for over 10 major releases. I would like to suggest we remove it in the Boost 1.68.0 release.
i had been working on one project, that was never migrated from signals to signals2, as attempts to migrate miserably failed: compile times significantly increased and the msvc linker would run out of memory.
this project is currently migrated away from boost.signals (1 and 2) to a more lightweight solution (nod signals), but i can imagine that there are some projects out there which still use signals(1) and which would run into trouble when it will be removed completely.
otoh i wonder if signals1 causes much maintenance overhead, that justifies potentially breaking downstream code
A standard response to something like this is that you can maintain the Boost.Signals 1 library from within your own repository even as it gets removed from Boost. -- David
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of David Sankel via Boost Sent: Friday, June 8, 2018 2:40 PM
On Tue, May 29, 2018 at 11:11 PM, Tim Blechmann via Boost < boost@lists.boost.org> wrote:
This first implementation of signals has been deprecated since the 1.54 release. (When) are we going to remove it? It is under management of the CMT, and it has been deprecated for over 10 major releases. I would like to suggest we remove it in the Boost 1.68.0 release.
As Paul suggested, I'd also vote for giving a removal warning for 1-2 release cycles first, but then remove it.
i had been working on one project, that was never migrated from signals to signals2, as attempts to migrate miserably failed: compile times significantly increased and the msvc linker would run out of memory.
this project is currently migrated away from boost.signals (1 and 2) to a more lightweight solution (nod signals), but i can imagine that there are some projects out there which still use signals(1) and which would run into trouble when it will be removed completely.
otoh i wonder if signals1 causes much maintenance overhead, that justifies potentially breaking downstream code
A standard response to something like this is that you can maintain the Boost.Signals 1 library from within your own repository even as it gets removed from Boost.
+1.
-- David
Mike
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Olaf van der Spek via Boost Sent: 20 June 2018 09:06 To: boost@lists.boost.org Cc: Olaf van der Spek Subject: Re: [boost] Boost.Signals deprecation and removal
On Mon, Jun 18, 2018 at 10:12 PM, mike via Boost <boost@lists.boost.org> wrote:
As Paul suggested, I'd also vote for giving a removal warning for 1-2 release cycles first, but then remove it.
Isn't deprecation the warning?
Yes, but not a serious 'you've got to do something next release' warning ;-) A removal warnings in this upcoming release notes? (I think you can still sneak a 'docs' item into this pending release's notes?) Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Isn't deprecation the warning? Yes, but not a serious 'you've got to do something next release' warning ;-)
A removal warnings in this upcoming release notes?
Even better - put a #pragma warning in the headers to say that it's going to be imminently removed. John. --- This email has been checked for viruses by AVG. https://www.avg.com
This is for Boost.Signals as opposed to Boost.Signals2, I suppose? On Fri, Jun 22, 2018 at 8:25 AM, Paul A. Bristow via Boost < boost@lists.boost.org> wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Olaf van der Spek via Boost Sent: 20 June 2018 09:06 To: boost@lists.boost.org Cc: Olaf van der Spek Subject: Re: [boost] Boost.Signals deprecation and removal
On Mon, Jun 18, 2018 at 10:12 PM, mike via Boost <boost@lists.boost.org> wrote:
As Paul suggested, I'd also vote for giving a removal warning for 1-2 release cycles first, but then remove it.
Isn't deprecation the warning?
Yes, but not a serious 'you've got to do something next release' warning ;-)
A removal warnings in this upcoming release notes?
(I think you can still sneak a 'docs' item into this pending release's notes?)
Paul
--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
On Fri, Jun 22, 2018 at 2:49 PM Emil Dotchevski via Boost < boost@lists.boost.org> wrote:
This is for Boost.Signals as opposed to Boost.Signals2, I suppose?
Correct, this is for Boost.Signals. I am going to add a release note to 1.68.0 indicating that Boost.Signals will be removed in an upcoming release and folks should migrate to Boost.Signals2. Signals was deprecated in 1.54.0 (about 5 years ago). - Jim
participants (9)
-
David Sankel -
Emil Dotchevski -
James E. King III -
James E. King, III
-
John Maddock -
mike.dev＠gmx.de -
Olaf van der Spek -
Paul A. Bristow -
Tim Blechmann