Hi,
Since v8 is the LTS version of NodeJS, and we use Nodejs only for development, test and build, I think we should drop the support of v6 and move entirely to v8.
I am not sure about the build process, but travis run tests against 8, 6 and 6.10:
node_js:
- '6.10' # current EPEL 7
- '6' # current LTS
- '8' # current stable
Any thoughts?
Thanks!
IIRC, these are the versions that are available on our builders currently - the builders run the OS they build for. On EL7 (Centos) this is limited by the version available in EPEL, which is currently 6.12.
I think on the debian-based distros we use NodeSource version which allows us to use 8, since Ubuntu Xenial ships with 4.2 and Debian Strech has 4.8.
Perhaps @packaging team will have further insights.
@tbrisker is correct that they are used to build packages so we can’t just drop older versions.
Why can’t we upgrade our centos builders to use https://nodesource.com/ ?
deb’s already do that?
IMHO since we don’t actually ship any npm/node binaries and its only used
for build time, we should be able to use it?
What are the benefits of the newer version? Also note that the katello devel env in forklift is based on CentOS 7 and our instructions also point to EPEL.
It is the long term support version.
v6 will stop being active at April 2018.
v8 will stop being active at April 2019.
Except the support benefit of v8, it should ship with better performance.
Most of the UI team is working with v8 as the development environment.
If it’s not about features and v6 is still supported for now then I
think it’s a low priority to drop v6. If it was a support burden on us
now then it’d be higher but at least I have plenty of other backlog that
already is a burden.
Sure, I agree it is not an high priority, i just think it is not making any sense to work with v6 in 2018 but nothing argent.
From my side it is a “nice to have”, will mostly allow me to drop the v6 tests from travis.
I think that because we don’t use it on run-time, the migration should be easy. (install nvm and run nvm install 8?)
I agree we should move away from it before April, but it’s likely it ends up being February or March. It’s good to check what EPEL plans to do since (I assume) want supported software.
AFAIR epel is planning to move to it in October (reading though https://fedoramagazine.org/node-js-6-x-lts-coming-epel-7/).
which imho would be too late for us, as most of the ecosystem will move away from nodejs 6.
if its not a lot of effort (or we would have to do it anyway) I think the sooner the better… thanks!
Given our build system, this is not an easy shift to make. We rely on the versions EPEL provides to build RPMs. If we drop support for what EPEL provides we risk breaking our RPM production installations. This leaves us with three options:
Option #1 requires no work. Option #2 we’ve talked about in the past and will require some work to flush out. Option #3 is the most work as it requires re-writing and re-building all of our nodejs packages.
Eric
I don’t know about the inner working of the whole RPM packaging, but for Debian using the nodesource repos was a 100% compatible dropin-replacement, so I’m seeing an option
However, I also don’t see a real pressure after April to drop NodeJS 6.x. Maybe I’m wrong, but I dont think e.g. using NodeJS 4.x these days would be really painful.
RPM building requires a yum repository that is publicly available to add to Koji as an external repository. As long as they provide that we could consider switching to using them. One thing to note, currently nodesource does not have NodeJS 8 support for RPM (https://github.com/nodesource/distributions/tree/master/rpm)
I’d say only the setup script is missing, https://rpm.nodesource.com/pub_8.x/el/7/x86_64/ looks OK.
