Boost.Signals deprecation and removal

Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Boost.Signals deprecation and removal

Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of James E. King, III via Boost
> Sent: 27 May 2018 19:22
> To: [hidden email]
> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
On Tue, May 29, 2018 at 11:11 PM, Tim Blechmann via Boost <
[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list


> -----Original Message-----
> From: Boost <[hidden email]> 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 <
> [hidden email]> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
On Mon, Jun 18, 2018 at 10:12 PM, mike via Boost <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost