[container][interprocess][intrusive][move] Removing support for old compilers

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

[container][interprocess][intrusive][move] Removing support for old compilers

Boost - Dev mailing list
Hi,

My libraries have supported quite old compilers, starting from Visual
2003 and GCC 3.4 and I'm asking for feedback before I start dropping old
compilers. The number of supported plus locally+regression tested
versions has increased a lot these years and that's a lot of work with
reduced benefits.

I run locally for:

- From Mingw GCC 3.4 to GCC 8.1, all released minor versions (combining
C++03-C++11-C++14-C++14).

- From MSVC 7.1 to MSVC 14.1, all released versions (default language
standard).

I also run boost regression tests for many of those compilers (see
"igaztanaga-*" runners in
https://www.boost.org/development/tests/master/developer/summary.html).

The number of supported and tested compilers is now unmanageable for me
as many of those have specific warnings/bugs that I try to fix. So I was
thinking about reducing that list a bit dropping support for the oldest
ones and replacing them with recent GCC/Clang from WSL (Windows
Subsystem for Linux).

My first idea is to drop anything older than 10 years, which means that
the minimum will be MSVC 9.0 and GCC 4.3 (both released in 2008).

I've reviewed some popular long support Linux distributions:

-> RHEL 6 uses GCC 4.4.
-> SUSE Linux Enterprise Server 11 Service Pack 4 (SP4) uses GCC 4.3

Microsoft no longer supports Visual 2008 (support ended on April 2018)
but I can continue compiling and testing it at least for another year.

Note that my libraries will continue support for -std=C++03, but I will
not find workarounds or fixes for old GCC and MSVC versions.

Thoughts, problems, comments?

Best,

Ion

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

Re: [container][interprocess][intrusive][move] Removing support for old compilers

Boost - Dev mailing list
On 10/1/18 4:58 PM, Ion Gaztañaga via Boost wrote:

> Hi,
>
> My libraries have supported quite old compilers, starting from Visual
> 2003 and GCC 3.4 and I'm asking for feedback before I start dropping old
> compilers. The number of supported plus locally+regression tested
> versions has increased a lot these years and that's a lot of work with
> reduced benefits.
>
> My first idea is to drop anything older than 10 years, which means that
> the minimum will be MSVC 9.0 and GCC 4.3 (both released in 2008).
>
> Thoughts, problems, comments?

I don't think there is any significant demand for ancient compilers like
MSVC 7.1 or gcc < 4.1, so I'm perfectly fine with dropping them. Your
list of supported compilers looks ok to me, even a little on the
conservative side. I would drop gcc 4.3 as well, despite it is used in
SLES 11. Old enterprise distros are not very representative, since new
Boost releases are unlikely to be used there anyway.

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

Re: [container][interprocess][intrusive][move] Removing support for old compilers

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/1/2018 9:58 AM, Ion Gaztañaga via Boost wrote:

> Hi,
>
> My libraries have supported quite old compilers, starting from Visual
> 2003 and GCC 3.4 and I'm asking for feedback before I start dropping old
> compilers. The number of supported plus locally+regression tested
> versions has increased a lot these years and that's a lot of work with
> reduced benefits.
>
> I run locally for:
>
> - From Mingw GCC 3.4 to GCC 8.1, all released minor versions (combining
> C++03-C++11-C++14-C++14).
>
> - From MSVC 7.1 to MSVC 14.1, all released versions (default language
> standard).
>
> I also run boost regression tests for many of those compilers (see
> "igaztanaga-*" runners in
> https://www.boost.org/development/tests/master/developer/summary.html).
>
> The number of supported and tested compilers is now unmanageable for me
> as many of those have specific warnings/bugs that I try to fix. So I was
> thinking about reducing that list a bit dropping support for the oldest
> ones and replacing them with recent GCC/Clang from WSL (Windows
> Subsystem for Linux).
>
> My first idea is to drop anything older than 10 years, which means that
> the minimum will be MSVC 9.0 and GCC 4.3 (both released in 2008).
>
> I've reviewed some popular long support Linux distributions:
>
> -> RHEL 6 uses GCC 4.4.
> -> SUSE Linux Enterprise Server 11 Service Pack 4 (SP4) uses GCC 4.3
>
> Microsoft no longer supports Visual 2008 (support ended on April 2018)
> but I can continue compiling and testing it at least for another year.
>
> Note that my libraries will continue support for -std=C++03, but I will
> not find workarounds or fixes for old GCC and MSVC versions.
>
> Thoughts, problems, comments?

I do not think supporting gcc versions before 4.8 is really necessary.
Gcc has put out various releases of versions 5, 6, 7, and now 8.1 since
then and I can hardly imagine anyone sticking to some version below 4.8
with all those releases. The first mingw-64/gcc version supported is 4.8
and that is good enough for me as it seems to work decently.

With VC++ anything before vs2008 is unnecessary and even vs2008 itself
is problematical, even though PP and VMD still "support" it, but I am
glad to hear that supported ended in April of this year. Even VS2010 has
some serious problems, so I could see just supporting from VS2012 on up
at the very minimum.

I would not worry much about dropping these older compilers. Nobody
should really be using them anymore in realistic C++ programming
environments. You sight RHEL6 but the vast majority of RHEL users are
probably on some release of RHEL7 by now, which CentOS7 has long shown
me to be very solid. Also SUSE has gone past version 11 a long time ago,
with many new releases ( I occasionally run the latest OpenSuse 15 on my
desktop ), and is also a very solid Linux distro, so I would be
surprised if there are many users of such an old release.

I do not think it is Boost's job to support older releases "forever",
especially given the many and better newer releases of gcc, VC++, and
clang, among others.

As far as c++03 is concerned I have stated my opinion that if more
modern features of c++11 do not bring any advantage for a library there
is not reason to upgrade just for the sake of supporting a higher c++
standard mode as long as higher modes work without problems, but I do
not think it is necessary to test at the c++03 level anymore.

>
> Best,
>
> Ion


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

Re: [container][interprocess][intrusive][move] Removing support for old compilers

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Ion Gaztañaga wrote:

> My first idea is to drop anything older than 10 years, which means that
> the minimum will be MSVC 9.0 and GCC 4.3 (both released in 2008).

A good heuristic is to not support anything not present on Travis and
Appveyor, which at the moment translates to GCC 4.4, Clang 3.3 and MSVC 9.0.
This is very close to what you've chosen.

(As a general observation, pull requests that break GCC < 5, MSVC < 12.0
often get merged, so Boost overall isn't likely to work very well on them,
although individual libraries might. The Travis superproject build is
catching some of the GCC 4.8 issues, but not all, and GCC 4.4 and 4.6 are
being paid close to no attention.)


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

Re: [container][interprocess][intrusive][move] Removing support for old compilers

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Edward Diener wrote:

> I do not think supporting gcc versions before 4.8 is really necessary.
...
> I would not worry much about dropping these older compilers. Nobody should
> really be using them anymore in realistic C++ programming environments.

I don't quite agree.

It is absolutely reasonable to drop support for ancient compilers if this
impedes further development of a library.

However, for libraries that have been written when those compilers were
current, have always supported them, and are presently in maintenance mode,
I do not view it as reasonable to break those compilers out of spite or out
of negligence.

If a library has always worked on GCC 4.4, we should try to keep it working
until GCC 4.4 is officially pronounced dead.

(A compiler is officially pronounced dead when Ion announces that he'll no
longer support it. :-) )


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

Re: [container][interprocess][intrusive][move] Removing support for old compilers

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


On 01/10/2018 16:46, Peter Dimov via Boost wrote:

> Ion Gaztañaga wrote:
>
>> My first idea is to drop anything older than 10 years, which means
>> that the minimum will be MSVC 9.0 and GCC 4.3 (both released in 2008).
>
> A good heuristic is to not support anything not present on Travis and
> Appveyor, which at the moment translates to GCC 4.4, Clang 3.3 and
> MSVC 9.0. This is very close to what you've chosen.
>
> (As a general observation, pull requests that break GCC < 5, MSVC <
> 12.0 often get merged, so Boost overall isn't likely to work very well
> on them, although individual libraries might. The Travis superproject
> build is catching some of the GCC 4.8 issues, but not all, and GCC 4.4
> and 4.6 are being paid close to no attention.)

With respect to older compilers, it's also worth asking what kind of
support we should expect - for example gcc-4.4 is a pretty reasonable
C++03 compiler, but personally I refuse to continue to support C++0x
mode when that pre-dates the standard and varies from it quite
considerably.   4.6 and 4.7 also have enough foibles in C++0x mode to
require a fair number of workarounds, but once we get to 4.8 the
compiler is good enough not to require too many herculean efforts to
support.

Just my 2c.... John.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [container][interprocess][intrusive][move] Removing support for old compilers

Boost - Dev mailing list
John Maddock wrote:

> With respect to older compilers, it's also worth asking what kind of
> support we should expect - for example gcc-4.4 is a pretty reasonable
> C++03 compiler, but personally I refuse to continue to support C++0x mode
> when that pre-dates the standard and varies from it quite considerably.
> 4.6 and 4.7 also have enough foibles in C++0x mode to require a fair
> number of workarounds, but once we get to 4.8 the compiler is good enough
> not to require too many herculean efforts to support.

As I said in my other message, what I consider reasonable is for things that
used to work to remain working. So if a library used to work with g++ 4.4
cxxstd=0x, we should try to maintain it in a working condition, but if it
never worked, there is no point in expending effort to make it work.

Pure backward compatibility, in other words.

In practice breakage occurs when one does "#if this C++11 feature is
supported, do that", and gcc 4.4 (or 4.6) advertises support for this C++11
feature, but the newly introduced code doesn't work there. This is easy
enough to fix as long as someone notices. (The case on earlier MSVCs is
similar because they introduced support for C++11 features in a
counter-intuitive order, for instance <tuple> before variadic templates and
so on.)


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

Re: [container][interprocess][intrusive][move] Removing support for old compilers

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
El 01/10/2018 a las 19:18, John Maddock via Boost escribió:
> With respect to older compilers, it's also worth asking what kind of
> support we should expect - for example gcc-4.4 is a pretty reasonable
> C++03 compiler, but personally I refuse to continue to support C++0x
> mode when that pre-dates the standard and varies from it quite
> considerably.   4.6 and 4.7 also have enough foibles in C++0x mode to
> require a fair number of workarounds, but once we get to 4.8 the
> compiler is good enough not to require too many herculean efforts to
> support.

I locally test C++0x modes starting on GCC 4.6, C++14 starting from GCC
4.9 and C++17 starting from GCC 7.1.

Any recommendation on first C++14 and C++17 versions?

Best,

Ion

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

Re: [container][interprocess][intrusive][move] Removing support for old compilers

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
El 01/10/2018 a las 17:56, Peter Dimov via Boost escribió:
> (A compiler is officially pronounced dead when Ion announces that he'll
> no longer support it. :-) )

Proud to be the Last of the Mohicans ;-)


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

[container][interprocess][intrusive][move] Removing support for old compilers

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
As you probably know, I'm not a boost library maintainer myself, but have
been pushing for boost to shed old cruft (e.g. dropping c++03 support in
boost completely), so take the following with a grain of salt:

> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Ion Gaztañaga via Boost
> Sent: Monday, October 1, 2018 3:59 PM
>
> [...]
>
> I've reviewed some popular long support Linux distributions:
>
> -> RHEL 6 uses GCC 4.4.
> -> SUSE Linux Enterprise Server 11 Service Pack 4 (SP4) uses GCC 4.3
>

As Andrey said, I wouldn't be too concerned with old enterprise distros.
The users that do want to use new boost releases on those distributions
actually have supported access to more recent toolchains via sdks/development
tools. Personally I would focus on the default compiler versions on
distributions that are still within their regular support period when you
actually drop the support. (E.g. SUSE LES 11 will enter extended support
on April 2019, so I'd rather look at SUSE LES 12 and RHEL 7 for the same
reason)

Don't forget the pipeline delay here:

- You probably want to give a warning that compiler version X.Y will no
  longer be supported in boost version 1.W one or two releases in advance
  (1.W-1 or even 1.W-2 ).
 
- When boost 1.W is released, it will take some time until it is made
  available to the developers writing applications for those platforms
  (e.g. due to company internal testing and upgrade cycles)

- The user of your library might have a release cycle of their own

- Finally, the user of the application using boost 1.W will have an upgrade
  cycle of their own an probably not employ the new software version the
  day it is released.

This is of course the worst case scenario and it depends e.g. on whether
your library is used in an in-house application or a sold software product,
but there may easily be 1-x years between the point that you decide you
want to drop support for toolchain version X.Y and the point when an
application using your library actually would be deployed on a production
system using that toolchain.  

Finally, boost is open source and free - if a company really wants to use
a long-outdated c++ toolchain with the latest version of boost, they can
pay someone to implement the necessary workarounds. So unless you are
getting payed to support those libraries, you don't have to feel too bad
if you make your life a little easier.

If supporting gcc4.4 or VS2008 doesn't cost you much time and effort: Great!
Keep supporting them! Otherwise, better switch to something more recent
and invest the saved time on new features, other improvements or just life
with your family.

Best

Mike


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