Project

General

Profile

Actions

Task #5087

closed

Drop support for Ubuntu 16.04 and CentOS 7

Added by Davide Pesavento almost 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Category:
Build
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

Description

Ubuntu 20.04 will be released on April 23, 2020. Per platform policy, that means we can drop support for 16.04 and raise our minimum requirement to 18.04. Similarly, we should also drop CentOS 7 support and require CentOS 8 or later.
As a consequence, we can raise the minimum version of toolchain components and various other dependencies. I suggest the following:

  • gcc >= 7
  • clang >= 5
  • boost >= 1.65.1
  • openssl >= 1.1.1

Potentially, we could also switch the codebase to C++17, but I'll consider that separately at a later time.
(updated plan: see #5087-14)


Related issues 5 (0 open5 closed)

Blocked by NFD - Task #5045: Release 0.7.0ClosedAlex Afanasyev

Actions
Blocked by NFD - Task #5040: Deploy CentOS 8 Jenkins agentsClosedDavide Pesavento

Actions
Blocked by NFD - Task #5085: Upgrade armhf Jenkins agents to Ubuntu 18.04ClosedMd Ashiqur Rahman

Actions
Blocked by NFD - Task #5093: Upgrade i386 Jenkins agents to Ubuntu 18.04ClosedMd Ashiqur Rahman

Actions
Blocked by NFD - Task #4904: Upgrade testbed nodes to Ubuntu 18.04ClosedJohn DeHart

Actions
Actions #1

Updated by Davide Pesavento almost 5 years ago

Actions #2

Updated by Davide Pesavento almost 5 years ago

  • Blocked by Task #5040: Deploy CentOS 8 Jenkins agents added
Actions #3

Updated by Davide Pesavento almost 5 years ago

  • Blocked by Task #5085: Upgrade armhf Jenkins agents to Ubuntu 18.04 added
Actions #4

Updated by Davide Pesavento almost 5 years ago

  • Related to Task #5093: Upgrade i386 Jenkins agents to Ubuntu 18.04 added
Actions #5

Updated by Davide Pesavento almost 5 years ago

  • Related to deleted (Task #5093: Upgrade i386 Jenkins agents to Ubuntu 18.04)
Actions #6

Updated by Davide Pesavento almost 5 years ago

  • Blocked by Task #5093: Upgrade i386 Jenkins agents to Ubuntu 18.04 added
Actions #7

Updated by Davide Pesavento over 4 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

CentOS 7 testing has been dropped from all jenkins projects where it was previously enabled (ndn-cxx, NFD, ndn-tools)

Actions #8

Updated by Davide Pesavento over 4 years ago

  • Blocked by Task #4904: Upgrade testbed nodes to Ubuntu 18.04 added
Actions #9

Updated by Davide Pesavento over 4 years ago

  • % Done changed from 10 to 30

CentOS 7 support removed from CI scripts.

Actions #10

Updated by Eric Newberry over 4 years ago

Can we accelerate the retirement of 16.04 to reduce the load on maestro, which is likely causing spurious timeout failures?

Actions #11

Updated by Eric Newberry over 4 years ago

Eric Newberry wrote:

Can we accelerate the retirement of 16.04 to reduce the load on maestro, which is likely causing spurious timeout failures?

The platform call on April 16, 2020 didn't raise any objections to proceeding with the retirement of 16.04.

Actions #12

Updated by Eric Newberry over 4 years ago

The 16.04 agents have been removed from Jenkins and all project configurations.

Actions #13

Updated by Davide Pesavento over 4 years ago

  • Description updated (diff)
  • % Done changed from 30 to 50
Actions #14

Updated by Davide Pesavento over 4 years ago

Davide Pesavento wrote:

As a consequence, we can raise the minimum version of toolchain components and various other dependencies. I suggest the following:

  • gcc >= 7
  • clang >= 5
  • boost >= 1.65.1
  • openssl >= 1.1.1

Alex objected to raising the minimum requirements, as he needs to support an old version of openwrt. Therefore, while we strongly encourage users to use the above minimum versions (and Ubuntu 18.04 remains the oldest version tested in jenkins), at this time we will not take any explicit steps to break compatibility with older versions of gcc, boost, and openssl.

Actions #15

Updated by Junxiao Shi over 4 years ago

Alex objected to raising the minimum requirements, as he needs to support an old version of openwrt.

When I mentioned that I have OpenWrt 18.06, I'm told that I must upgrade the OS and stop buying #CrappyHardware.
When Alex wants to support OpenWrt 18.06, he can keep the version support.
Double standard.

Actions #16

Updated by Davide Pesavento over 4 years ago

Junxiao Shi wrote:

Alex objected to raising the minimum requirements, as he needs to support an old version of openwrt.

When I mentioned that I have OpenWrt 18.06, I'm told that I must upgrade the OS and stop buying #CrappyHardware.
When Alex wants to support OpenWrt 18.06, he can keep the version support.
Double standard.

You never voiced your concerns here on this issue, or during any recent NDN calls, or on gerrit. In fact, you were invited to review the initial version of the change that raised the minimum requirements, and not only you didn't object, but you explicitly gave it a +1.
So please refrain from making these false accusations.

Actions #17

Updated by Junxiao Shi over 4 years ago

I put +1 because the commit matches the task. It doesn't mean I'm not pissed.

Actions #18

Updated by Davide Pesavento over 4 years ago

  • Description updated (diff)
  • Status changed from In Progress to Code review
  • % Done changed from 50 to 100
Actions #19

Updated by Davide Pesavento over 4 years ago

  • Status changed from Code review to Closed
Actions #20

Updated by Junxiao Shi over 4 years ago

Alex objected to raising the minimum requirements, as he needs to support an old version of openwrt.

This is getting ridiculous. I got this code review comment:

we're trying to avoid breaking compat with boost 1.58.0 so don't use data-driven tests yet please.

The OpenWrt build system does not run the unit tests, and therefore it should be perfectly fine to use Boost 1.65 features in unit testing.

Actions #21

Updated by Alex Afanasyev over 4 years ago

Not sure why do you like commenting on old issues instead of having a normal conversation in Gerrit. You have a valid point of including the data-driven test and I have no objections. Davide's comment was a suggestion, as you could do the same without introducing dependency. But in any case, the referred "compatibility" is best effort and I would prefer having the main codebase compilable with older versions of Boost. Others may disagree, but tests for me not the main codebase, and one can take a leap of faith and compile the code without tests (or compile with some tests removed).

Actions

Also available in: Atom PDF