loopbackio/loopback-connector

breaking change in 4.9.0 due to drop of node 6 support

regevbr opened this issue · 8 comments

regevbr commented

Hi,

You have dropped support for node 6 in version 4.9.0 which is completely acceptable as it is EOL, but that is a braking change and in order to adhere to semver, you can't publish that breaking change under the same major version.
Sadly, I'm still using node 6 and your change broke all my repositories.

Can you please roll back the release and make the changes in a new major version?

Thanks,

achrinza commented

AFAIK the changes aren't exactly backwards-incompatible, based on that my suggestion is:

  • Re-publish 4.10.2 as 4.11.0 with Node.js 6 support
  • Do not remove 4.9.0
  • Re-publish 4.11.0 as 5.0.0, dropping Node.js 6 support See below
  • Add docs on backwards-incompatible 4.9.0
  • Update direct dependencies for other lb projects

It seems like these connectors have the same issue with dropping Node.js 6 support under a semver minor:

Based on Module LTS, there shouldn't be a need to drop Node.js versions unless a breaking change was necessary to be compatible with the latest Node.js version:

there is the possibility that a module could be incompatible with the latest version of Node. In this case, the module should be updated. If breaking changes are required this would consistute a new major version of the module, and this new version would have the same End of Life date as the latest version of Node.

/cc @strongloop/loopback-admins

raymondfeng commented

For the record: When we drop 6.x or 8.x, what we really did was to change engines in package.json. The module is still available for applications that run with lower version of node.

See https://docs.npmjs.com/files/package.json#engines:

Unless the user has set the engine-strict config flag, this field is advisory only and will only produce warnings when your package is installed as a dependency.

regevbr commented

The changes are not node 6 compatible, such as using spread operators...
If the change was just in the engines field, I wouldn't have opened the issue.

  • 👍1
achrinza commented

@regevbr thanks for the info;

Regrettably this may be a bit more difficult, as rolling back minor versions is a backwards-incompatible change in itself.

A possible suggestion:

  • Re-publish 4.8.0 as 4.11.0
  • Do not remove 4.9.0 - 4.10.2 to keep existing package locks functioning.
  • Re-publish 4.10.2 as 5.0.0
  • Add docs on backwards-incompatible 4.9.0 - 4.10.2
  • Update direct dependencies for other lb projects to 5.0.0

This may break other projects that are already utilising 4.10.2 just fine. However, the changes may be minute enough that it may not be a concern.

  • 👍1
bajtos commented

Thank you @regevbr for opening the discussion. I agree with you that ideally, when we remove support for a major Node.js version (e.g. 6.x), then we should publish a major version of our module too.

Unfortunately, this does not work well with our LTS support policy. If we keep supporting EOL versions of Node, and there is a security vulnerability discovered in one of our dependencies, and this vulnerability is fixed in the latest version only, and that latest version no longer supports EOLed version of Node, then we cannot get the fix. If we are not able to fix security vulnerabilities in our LTS versions, then it's IMO no long-term support at all.

We have discussed this for a bit around Node.js 4.x release (pretty much the first relevant release after 2-3 years of having everybody on Node.js 0.10). I believe we reached the conclusion that when having to choose between security fixes and strict adherence to semver rules, we prefer security over user convenience.

BTW this gets even more complicated for major versions of the framework itself (e.g. loopback and loopback-datasource-juggler module). When LB 3.x is Current and LB 2.x is Active LTS, and Node.js 6.x goes EOL, then how should be drop support for Node.js 6.x from LB 2.x? LB 3.x is already taken at that point...

My recommendation is to use package-lock and npm-shrinkwrap functionality to lock down your dependencies to the latest versions that still support Node.js 6.x.

BTW I hope that you are aware that both Node.js versions 6.x and 8.x contain known security vulnerabilities?

regevbr commented

Hi @bajtos

Thanks for a very detailed response!

I understand your concerns, and I hope that you will find a better way to handle it in future products.

I'm aware of the issues, and working hard towards upgrading my node versions, but that will take time...

bajtos commented

I understand your concerns, and I hope that you will find a better way to handle it in future products.

Thank you! ❤️

I'm aware of the issues, and working hard towards upgrading my node versions, but that will take time...

I am sorry for the troubles we caused. I know from my personal experience how annoying it can be when something that is working perfectly fine suddenly requires a lot of attention because the landscape provided by dependencies shifted a lot.

Good luck! 🍀

regevbr commented

Thank you!