Suggested policy for dropping C++03 support in Boost libraries

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
We need a policy on phasing out C++03 support in Boost.

C++03 support is holding us back. It impedes development, increases
maintenance costs, increases dependencies, and increases compilation times.

Library authors and maintainers need to have an approved mechanism for
dropping C++03 support in their libraries.

The suggested way forward is to allow library authors to declare C++03
support deprecated via a notice in the documentation and a message issued at
compile time, then be allowed to drop C++03 support no earlier than three
Boost releases later.

For instance, a library may declare C++03 support deprecated in Boost 1.73,
and drop it no earlier than in Boost 1.76.

More at https://pdimov.github.io/articles/phasing_out_cxx03.html.


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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list


On November 7, 2019 3:10:12 PM EST, Peter Dimov via Boost <[hidden email]> wrote:
> We need a policy on phasing out C++03 support in Boost.
>
> C++03 support is holding us back. It impedes development, increases
> maintenance costs, increases dependencies, and increases compilation
> times.

+1

Consider the alternate path of bumping the major version. There are a lot of libraries that will have to drop 03 simultaneously, so that would be signified clearly by a move to Boost v2.

There may be some tooling that assumes v1, but really, isn't it time to use the major version number?
--
Rob

(Sent from my portable computation device.)

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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
On 2019-11-08 00:42, Rob Stewart via Boost wrote:

>
>
> On November 7, 2019 3:10:12 PM EST, Peter Dimov via Boost <[hidden email]> wrote:
>> We need a policy on phasing out C++03 support in Boost.
>>
>> C++03 support is holding us back. It impedes development, increases
>> maintenance costs, increases dependencies, and increases compilation
>> times.
>
> +1
>
> Consider the alternate path of bumping the major version. There are a lot of libraries that will have to drop 03 simultaneously, so that would be signified clearly by a move to Boost v2.
>
> There may be some tooling that assumes v1, but really, isn't it time to use the major version number?

If we are going to start purposely dropping C++03 then I agree it's time
for Boost 2.x.

Though I'm not sure exactly what is being proposed. Are we (library
maintainers) expected to actively drop C++03 and port our libraries to
C++11+? What if we don't, for whatever reason?

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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list

On 2019-11-07 4:42 p.m., Rob Stewart via Boost wrote:
>
> On November 7, 2019 3:10:12 PM EST, Peter Dimov via Boost <[hidden email]> wrote:
>> We need a policy on phasing out C++03 support in Boost.
>>
>> C++03 support is holding us back. It impedes development, increases
>> maintenance costs, increases dependencies, and increases compilation
>> times.

I thought library authors already were at liberty to require C++11 for
their project. Are you suggesting that at this point in time all Boost
libraries are supposed to be compatible with C++03 ?


> Consider the alternate path of bumping the major version. There are a lot of libraries that will have to drop 03 simultaneously, so that would be signified clearly by a move to Boost v2.
>
> There may be some tooling that assumes v1, but really, isn't it time to use the major version number?

I never understood our versioning (numbering) scheme. Given that we
don't have any metric to measure the degree of (in-)compatibility
between two distinct Boost releases, I always thought a simple
monotonically increasing number would be the simplest. Let's just get
rid of the "1." as a meaningless prefix, rather than invent some
semantics around an illusion.

Stefan
--

       ...ich hab' noch einen Koffer in Berlin...


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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Andrey Semashev wrote:

> Though I'm not sure exactly what is being proposed. Are we (library
> maintainers) expected to actively drop C++03 and port our libraries to
> C++11+? What if we don't, for whatever reason?

What is being proposed is a sanctioned mechanism for library maintainers to
drop C++03 in an orderly manner. Any library maintainer who wishes to
maintain C++03 support is free to do so.


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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
On 11/7/19 2:27 PM, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
>
>> Though I'm not sure exactly what is being proposed. Are we (library
>> maintainers) expected to actively drop C++03 and port our libraries to
>> C++11+? What if we don't, for whatever reason?
>
> What is being proposed is a sanctioned mechanism for library maintainers
> to drop C++03 in an orderly manner. Any library maintainer who wishes to
> maintain C++03 support is free to do so.

I don't see any difference between this and the current policy.  As far
as I know no library developer has ever been required to provide support
for other than the current standard.  Of course if I'm wrong about this,
then feel free to make this policy explicit.  I don't see it changing
anything.


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


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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
On Thu, Nov 7, 2019 at 9:09 PM Robert Ramey wrote:

>
> On 11/7/19 2:27 PM, Peter Dimov via Boost wrote:
> > What is being proposed is a sanctioned mechanism for library maintainers
> > to drop C++03 in an orderly manner. Any library maintainer who wishes to
> > maintain C++03 support is free to do so.
>
> I don't see any difference between this and the current policy.  As far
> as I know no library developer has ever been required to provide support
> for other than the current standard.  Of course if I'm wrong about this,
> then feel free to make this policy explicit.  I don't see it changing
> anything.

It's different in this way: Some Boost authors and contributors do
feel constrained even if the official policy is to support only the
latest/current standard from breaking either an existing Boost library
that depends on that library that supports C++03, or breaking some
software that uses that Boost library which must be compiled in C++03.

For example, during a Boost beta release, reports might come in from
users saying that X library no longer works for them because they need
C++03 support. Or after a release, a Linux distribution package set
fails to build, because they compile those programs in C++03 mode, and
the Boost library stops compiling in C++03 mode.

But while that might have been the case three - maybe even two - years
ago, it isn't likely to be the case now. e.g. More compilers default
standard mode is C++14 now, not C++03. i.e. Those of us who were
worried about that outcome are less worried about it now.

Glen

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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
On 11/7/19 6:23 PM, Glen Fernandes via Boost wrote:

> On Thu, Nov 7, 2019 at 9:09 PM Robert Ramey wrote:
>>
>> On 11/7/19 2:27 PM, Peter Dimov via Boost wrote:
>>> What is being proposed is a sanctioned mechanism for library maintainers
>>> to drop C++03 in an orderly manner. Any library maintainer who wishes to
>>> maintain C++03 support is free to do so.
>>
>> I don't see any difference between this and the current policy.  As far
>> as I know no library developer has ever been required to provide support
>> for other than the current standard.  Of course if I'm wrong about this,
>> then feel free to make this policy explicit.  I don't see it changing
>> anything.
>
> It's different in this way: Some Boost authors and contributors do
> feel constrained even if the official policy is to support only the
> latest/current standard from breaking either an existing Boost library
> that depends on that library that supports C++03, or breaking some
> software that uses that Boost library which must be compiled in C++03.

Hmmm this is a big surprise to me.  My understanding has been that
anything that would compile with C++03 would be compilable with all the
subsequent versions of C++.  That is the guarantee of backward
compatibility.  There has been talk about breaking this guarantee, but
as far as I know it is still guaranteed.

> For example, during a Boost beta release, reports might come in from
> users saying that X library no longer works for them because they need
> C++03 support. Or after a release, a Linux distribution package set
> fails to build, because they compile those programs in C++03 mode, and
> the Boost library stops compiling in C++03 mode.
>
> But while that might have been the case three - maybe even two - years
> ago, it isn't likely to be the case now. e.g. More compilers default
> standard mode is C++14 now, not C++03. i.e. Those of us who were
> worried about that outcome are less worried about it now.

Hmm - for example, the boost serialization library is C++03 compatible,
but it compiles with std=C++14 just fine - exactly as guaranteed by the
standard.

Soooooo - you can make whatever policy you want, but I don't see how it
would the maintainer of the serialization library in any way.

Robert Ramey

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


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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
On Thu, Nov 7, 2019, 10:13 PM Robert Ramey via Boost <[hidden email]>
wrote:

> On 11/7/19 6:23 PM, Glen Fernandes via Boost wrote:
> > On Thu, Nov 7, 2019 at 9:09 PM Robert Ramey wrote:
> >>
> >> On 11/7/19 2:27 PM, Peter Dimov via Boost wrote:
> >>> What is being proposed is a sanctioned mechanism for library
> maintainers
> >>> to drop C++03 in an orderly manner. Any library maintainer who wishes
> to
> >>> maintain C++03 support is free to do so.
> >>
> >> I don't see any difference between this and the current policy.  As far
> >> as I know no library developer has ever been required to provide support
> >> for other than the current standard.  Of course if I'm wrong about this,
> >> then feel free to make this policy explicit.  I don't see it changing
> >> anything.
> >
> > It's different in this way: Some Boost authors and contributors do
> > feel constrained even if the official policy is to support only the
> > latest/current standard from breaking either an existing Boost library
> > that depends on that library that supports C++03, or breaking some
> > software that uses that Boost library which must be compiled in C++03.
>
> Hmmm this is a big surprise to me.  My understanding has been that
> anything that would compile with C++03 would be compilable with all the
> subsequent versions of C++.  That is the guarantee of backward
> compatibility.  There has been talk about breaking this guarantee, but
> as far as I know it is still guaranteed.
>
> > For example, during a Boost beta release, reports might come in from
> > users saying that X library no longer works for them because they need
> > C++03 support. Or after a release, a Linux distribution package set
> > fails to build, because they compile those programs in C++03 mode, and
> > the Boost library stops compiling in C++03 mode.
> >
> > But while that might have been the case three - maybe even two - years
> > ago, it isn't likely to be the case now. e.g. More compilers default
> > standard mode is C++14 now, not C++03. i.e. Those of us who were
> > worried about that outcome are less worried about it now.
>
> Hmm - for example, the boost serialization library is C++03 compatible,
> but it compiles with std=C++14 just fine - exactly as guaranteed by the
> standard.
>
> Soooooo - you can make whatever policy you want, but I don't see how it
> would the maintainer of the serialization library in any way.
>
> Robert Ramey
>
> >
> > Glen
> >
> >


This was already debated before.  No need to rehash it.  Maintainers are
already empowered to drop C++03 support.  They can start by updating their
readme and docs and stop running their C++03 CI jobs.

- Jim

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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
On 11/7/19 7:24 PM, James E. King III via Boost wrote:

>
> This was already debated before.  No need to rehash it.  Maintainers are
> already empowered to drop C++03 support.  

Right. they've been empowered to do this for 20 years.  How does this
change anything


> They can start by updating their
> readme and docs and stop running their C++03 CI jobs.

Is it being proposed that they should be required to do this?.  If not
what are library maintainers expected to do differently?

Robert Ramey



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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2019-11-08 05:23, Glen Fernandes via Boost wrote:

> On Thu, Nov 7, 2019 at 9:09 PM Robert Ramey wrote:
>>
>> On 11/7/19 2:27 PM, Peter Dimov via Boost wrote:
>>> What is being proposed is a sanctioned mechanism for library maintainers
>>> to drop C++03 in an orderly manner. Any library maintainer who wishes to
>>> maintain C++03 support is free to do so.
>>
>> I don't see any difference between this and the current policy.  As far
>> as I know no library developer has ever been required to provide support
>> for other than the current standard.  Of course if I'm wrong about this,
>> then feel free to make this policy explicit.  I don't see it changing
>> anything.
>
> It's different in this way: Some Boost authors and contributors do
> feel constrained even if the official policy is to support only the
> latest/current standard from breaking either an existing Boost library
> that depends on that library that supports C++03, or breaking some
> software that uses that Boost library which must be compiled in C++03.
>
> For example, during a Boost beta release, reports might come in from
> users saying that X library no longer works for them because they need
> C++03 support. Or after a release, a Linux distribution package set
> fails to build, because they compile those programs in C++03 mode, and
> the Boost library stops compiling in C++03 mode.

This new proposal doesn't change anything. If a developer feels the
obligation to support C++03 then it is an obligation before users, and
no document initiated by Boost changes that. If a developer wishes to
break that obligation and switch to C++11 then nothing prevented him to
do that before. Sure, there would be some fallout, and there will be
still after this proposal, so the preferred way to do that is to
introduce vX+1 of the library.

The only thing that could be changed is to forcefully upgrade all
libraries to require C++11 and call it Boost 2.x, but I'm not sure if
that would be useful. It would save each library from vX+1 hassle, at least.

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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 11/7/19 21:37, Robert Ramey via Boost wrote:
> On 11/7/19 7:24 PM, James E. King III via Boost wrote:
>
>>
>> This was already debated before.  No need to rehash it.  Maintainers are
>> already empowered to drop C++03 support. 
>
> Right. they've been empowered to do this for 20 years.  How does this
> change anything

It would seem that you are not the audience. Some authors apparently
feel conflict in dropping C++03 support. A clearly documented policy of
how to do this provides no harm and may cause authors/maintainers to
deprecate old compiler support.

>
>
>> They can start by updating their
>> readme and docs and stop running their C++03 CI jobs.
>
> Is it being proposed that they should be required to do this?.  If not
> what are library maintainers expected to do differently?
>

The proposal does not say this. The proposal provides the minimum steps
that should be taken when a library maintainer is going to deprecate
C++03 support.

It seems very reasonable to have a written policy. I fully understand
that some maintainers will feel no additional power from such a
declaration; however, it does allow a uniform process to be pointed to.

michael

--
Michael Caisse
Ciere Consulting
ciere.com

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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list


> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Michael Caisse via
> Boost
> Sent: 8 November 2019 07:18
> To: [hidden email]
> Cc: Michael Caisse <[hidden email]>
> Subject: Re: [boost] Suggested policy for dropping C++03 support in Boost libraries
>
> On 11/7/19 21:37, Robert Ramey via Boost wrote:
> > On 11/7/19 7:24 PM, James E. King III via Boost wrote:
> >
> >>
> >> This was already debated before.  No need to rehash it.  Maintainers
> >> are already empowered to drop C++03 support.
> >
> > Right. they've been empowered to do this for 20 years.  How does this
> > change anything
>
> It would seem that you are not the audience. Some authors apparently feel
> conflict in dropping C++03 support. A clearly documented policy of how to do this
> provides no harm and may cause authors/maintainers to deprecate old compiler
> support.
>
> >
> >
> >> They can start by updating their
> >> readme and docs and stop running their C++03 CI jobs.
> >
> > Is it being proposed that they should be required to do this?.  If not
> > what are library maintainers expected to do differently?
> >
>
> The proposal does not say this. The proposal provides the minimum steps that
> should be taken when a library maintainer is going to deprecate
> C++03 support.
>
> It seems very reasonable to have a written policy. I fully understand that some
> maintainers will feel no additional power from such a declaration; however, it does
> allow a uniform process to be pointed to.

I agree that the existing policy of 20 years has not changed, (but is frequently misunderstood) but agree that a statement of policy could be helpful to users.

The essence of Peter Dimov proposal https://pdimov.github.io/articles/phasing_out_cxx03.html is

Suggested Policy is

"
A library author or maintainer will be allowed to announce that C++03 support in the library is deprecated.

This announcement will take the following forms:

A note in the documentation;

An item in the release notes in the Boost release deprecating C++03 support;

A message issued at compilation time if a library header is included in C++03 mode.

The recommended form of the code issuing the message will be

#include <boost/config.hpp>
#include <boost/config/pragma_message.hpp>

#if defined(BOOST_NO_CXX11_VARIADIC_TEMPLATES) || defined(BOOST_NO_CXX11_RVALUE_REFERENCES) || defined(BOOST_NO_CXX11_HDR_MEMORY)

BOOST_PRAGMA_MESSAGE("C++03 support is deprecated in Boost.Library 1.73 and will be removed in Boost.Library 1.76.")

#endif
with the condition of the #if directive adjusted appropriately to reflect the actual library requirements.

At least three Boost releases must ship with a deprecation notice before support is dropped.
"
Previously, I think we had suggested only two releases (my preference).

But that still seems a reasonable policy to me.

Paul

Paul A. Bristow
Prizet Farmhouse
Kendal, Cumbria
LA8 8AB           UK




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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
On Fri, 8 Nov 2019 at 11:46, Paul A Bristow via Boost
<[hidden email]> wrote:

> The essence of Peter Dimov proposal https://pdimov.github.io/articles/phasing_out_cxx03.html is
>
> Suggested Policy is
> "
> A library author or maintainer will be allowed to announce that C++03 support in the library is deprecated.
> This announcement will take the following forms:
> A note in the documentation;
> An item in the release notes in the Boost release deprecating C++03 support;
> A message issued at compilation time if a library header is included in C++03 mode.
> The recommended form of the code issuing the message will be
> #include <boost/config.hpp>
> #include <boost/config/pragma_message.hpp>
> #if defined(BOOST_NO_CXX11_VARIADIC_TEMPLATES) || defined(BOOST_NO_CXX11_RVALUE_REFERENCES) || defined(BOOST_NO_CXX11_HDR_MEMORY)
> BOOST_PRAGMA_MESSAGE("C++03 support is deprecated in Boost.Library 1.73 and will be removed in Boost.Library 1.76.")
> #endif
> with the condition of the #if directive adjusted appropriately to reflect the actual library requirements.
> At least three Boost releases must ship with a deprecation notice before support is dropped.
> "

Let's assume this policy is accepted and implemented.
What happens to renegade libraries that switched to C++11
without following some/any of the policy rules?

For example, for GIL we just agreed internally within maintainers
on switch to C++11, made the grand clean up and announced it
in the release notes of Boost 1.68.

I understand GIL's impact on the world is much less than many of
other Boost libraries, so deprecating stuff in GIL may be even
unnoticed to majority of Boost users. I'm just using the case
as illustration to my question.

p.s. An off-topic digression regarding Stefan's comment on 1.x version, well,
it feels to me the `1` has entrenched so well into the Boost version number
that it will stay there fixed until the end of its life and one day longer.
If it ever changes, I will remain in shock for weeks ;-)

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 07.11.19 22:42, Rob Stewart via Boost wrote:
> Consider the alternate path of bumping the major version. There are a lot of libraries that will have to drop 03 simultaneously, so that would be signified clearly by a move to Boost v2.

I like this idea, for two reasons:

1. It lets us point to a definite last version of Boost to support
C++03.  Have a project that is stuck on C++03, but compiles with the
current latest version of Boost?  This is the specific version of Boost
that you should use.

2. It leaves open the door for an emergency maintenance release to the
C++03 line, in case any truly terrible bugs end up in that final 1.x
release.


--
Rainer Deyke ([hidden email])


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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Paul A Bristow wrote:

> Previously, I think we had suggested only two releases (my preference).

Two releases was what I initially had, then changed it to three (a full
year.)

But on second thought, two is enough, so I'll change it back to two if there
are no objections.


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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 11/8/19 3:44 AM, Rainer Deyke via Boost wrote:
> On 07.11.19 22:42, Rob Stewart via Boost wrote:
>> Consider the alternate path of bumping the major version. There are a
>> lot of libraries that will have to drop 03 simultaneously,

Hmmm - I'm not seeing this this.

  so that
>> would be signified clearly by a move to Boost v2.

So I'm not seeing that changing to 1 -> 2 would signify anything.

> 1. It lets us point to a definite last version of Boost to support
> C++03.  Have a project that is stuck on C++03, but compiles with the
> current latest version of Boost?  This is the specific version of Boost
> that you should use.

I don't see this either.  I'm sure that any library which works with
C++03 will work with C++20.  In fact, given that C++ purports to support
ABI compatibility, one should be able to compile each source file with
different C++ version switches.

>
> 2. It leaves open the door for an emergency maintenance release to the
> C++03 line, in case any truly terrible bugs end up in that final 1.x
> release.

I think that door is already open.

And of course, given the backward source and binary compatibility
presumably guaranteed by C++ the whole effort is pointless and will
confuse some people into thinking that these C++ features don't exist.

Having said this, I would expect that someday in the future, C++ will
drop and/or modify requirements for one or both of backward source
compatibility and ABI stability due to the burden that these place on
the evolution of the language.  At that point, one might think of
changing boost 1.xx to 2.xx. But that day is not yet here.  So the
concerns raised here are premature.

Robert Ramey


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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
On Fri, Nov 8, 2019 at 7:43 AM Robert Ramey  wrote:
> I don't see this either.  I'm sure that any library which works with
> C++03 will work with C++20.

What about this scenario: The maintainer of Boost.TypeTraits decides
to stop supporting C++03 and removes all C++03 workarounds and tests
for the  1.75 release. Serialization depends on TypeTraits, so in
1.75, Serialization cannot be used by C++03 users. Right now, the
release managers would probably hold up the 1.75 release because of
failing tests for Serialization. (Or if not failing tests, then maybe
they might hold up the release if users complain about the 1.75-beta's
Serialization not working for them).

The idea is the release managers would not hold up the release, for
something like that. i.e. C++03 Serialization tests wouldn't matter to
the release managers, only the C++11+ tests. User complaints about
C++03  support wouldn't matter to the release managers, because they
would reply saying that the standard mode is no longer officially
supported.

As the Boost Serialization author, you would be free to reimplement
those TypeTraits inside Boostorg/Serialization to keep your C++03
users happy. But the TypeTraits maintainer would feel like he can make
that change without any concerns.

If you believe that this is the way of things today, then there's
nothing to worry about. Everyone's already in agreement about the
state that we want to be in.

Glen

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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list


On November 7, 2019 5:18:28 PM EST, Stefan Seefeld via Boost <[hidden email]> wrote:

>
> On 2019-11-07 4:42 p.m., Rob Stewart via Boost wrote:
> >
> > On November 7, 2019 3:10:12 PM EST, Peter Dimov via Boost
> <[hidden email]> wrote:
> >> We need a policy on phasing out C++03 support in Boost.
>
> I thought library authors already were at liberty to require C++11 for
> their project. Are you suggesting that at this point in time all Boost
> libraries are supposed to be compatible with C++03 ?

Peter is only documenting how to go about making the transition, but my expectation is that it will encourage authors and maintainers to make the transition.

> > Consider the alternate path of bumping the major version. There are
> a lot of libraries that will have to drop 03 simultaneously, so that
> would be signified clearly by a move to Boost v2.
> >
> > There may be some tooling that assumes v1, but really, isn't it time
> to use the major version number?
>
> I never understood our versioning (numbering) scheme. Given that we
> don't have any metric to measure the degree of (in-)compatibility
> between two distinct Boost releases, I always thought a simple
> monotonically increasing number would be the simplest. Let's just get
> rid of the "1." as a meaningless prefix, rather than invent some
> semantics around an illusion.

Some tools probably expected a major and minor version number. (Even if that was the case, it may no longer be so.)

I suppose a v2 of Boost is illusory, so there's something to your idea.
--
Rob

(Sent from my portable computation device.)

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

Re: Suggested policy for dropping C++03 support in Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 11/8/19 4:58 AM, Glen Fernandes via Boost wrote:

> On Fri, Nov 8, 2019 at 7:43 AM Robert Ramey  wrote:
>> I don't see this either.  I'm sure that any library which works with
>> C++03 will work with C++20.
>
> What about this scenario: The maintainer of Boost.TypeTraits decides
> to stop supporting C++03 and removes all C++03 workarounds and tests
> for the  1.75 release. Serialization depends on TypeTraits, so in
> 1.75, Serialization cannot be used by C++03 users. Right now, the
> release managers would probably hold up the 1.75 release because of
> failing tests for Serialization. (Or if not failing tests, then maybe
> they might hold up the release if users complain about the 1.75-beta's
> Serialization not working for them).

Hmmmm - good observation.  My understanding of the policy "one is only
obligated to support the latest legal version of C++" would suggest that
release managers would not currently be required to enforce or even test
for compatibility with C++03.  So maybe this idea isn't aimed at library
authors but at release managers.  That would make sense.


> The idea is the release managers would not hold up the release, for
> something like that. i.e. C++03 Serialization tests wouldn't matter to
> the release managers, only the C++11+ tests. User complaints about
> C++03  support wouldn't matter to the release managers, because they
> would reply saying that the standard mode is no longer officially
> supported.

Correct - this makes sense to me.

> As the Boost Serialization author, you would be free to reimplement
> those TypeTraits inside Boostorg/Serialization to keep your C++03
> users happy. But the TypeTraits maintainer would feel like he can make
> that change without any concerns.

Agreed. The same situation that I'm on now.

> If you believe that this is the way of things today, then there's
> nothing to worry about. Everyone's already in agreement about the
> state that we want to be in.

Sounds like we all agree that we're already where we want to be and that
no change in policy is necessary.  Perhaps the only thing needed is for
release managers to announce that lack of C++03 compatibility is not
grounds for holding up a release so C++03 won't be tested any more.
Actually, I was not aware that C++03 was still being used to test anything.

One interesting thing -

The author of a library developed under C++03 doesn't really have much
if any incentive to "upgrade" the implementation to a later version. And
normally he doesn't because it doesn't add anything but more work.
Older libraries like serialization were developed depending on boost as
it existed at the time. So in practice, the scenario you cite above
doesn't seem to present itself much.  The only time I can see it
happening is when the author/maintainer of an older library might
re-implement using more up-to-date techniques.  Perhaps the intention of
this announcement is to provide cover for maintainers who want to do this.

Robert Ramey


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



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