Boost.Signals deprecation and removal

James E. King, III

27 May 2018 27 May '18

6:21 p.m.

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

Show replies by date

Paul A. Bristow

29 May 29 May

11:09 a.m.

...

-----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

Tim Blechmann

30 May 30 May

3:11 a.m.

...

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

David Sankel

8 Jun 8 Jun

12:40 p.m.

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

mike.dev＠gmx.de

18 Jun 18 Jun

8:12 p.m.

...

-----Original Message----- From: Boost 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

Olaf van der Spek

20 Jun 20 Jun

8:06 a.m.

On Mon, Jun 18, 2018 at 10:12 PM, mike via Boost 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? -- Olaf

Paul A. Bristow

22 Jun 22 Jun

3:25 p.m.

...

-----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 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

John Maddock

4:58 p.m.

...

...
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

Emil Dotchevski

6:48 p.m.

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 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

James E. King III

15 Jul 15 Jul

2:24 p.m.

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

2326

Age (days ago)

2375

Last active (days ago)

List overview

Download

9 comments

9 participants

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