Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3.3.2 -> 3.3.3 contains breaking change #54

Open
GraanJonlo opened this issue Jul 30, 2021 · 4 comments
Open

3.3.2 -> 3.3.3 contains breaking change #54

GraanJonlo opened this issue Jul 30, 2021 · 4 comments

Comments

@GraanJonlo
Copy link

Last release bumps jpeg-js from 0.3 to 0.4 which drops Node 6 support. This effectively means that get-pixels has now also dropped support for Node 6. I would argue that this is a breaking change. I propose 3.3.3 should be nerfed and re-released as 4.0.0

@striezel
Copy link

striezel commented Aug 1, 2021

Indeed. The release notes of jpeg-js 0.4 state some breaking changes, among other things that they

no longer support node versions before 8 LTS

So, yes, get-pixels 3.3.3 should technically be version 4.0.0 instead.


But I wonder: Do people really still use Node.js 6 today? Node 6 reached its end of life on 2019-04-01, more than two years ago. That's half an eternity in the JavaScript ecosystem, and it is so old I had to dig it up from the archives. Node 8 was EOL on 2019-12-31, and Node 10 on 2021-04-01, so people should be using at least Node 12 LTS these days. So anyone relying on Node 6 is at least six major releases (or three LTS release) behind and probably has a handful of known security issues in their Node version that would be fixed, if they used a current LTS release instead.

@GraanJonlo
Copy link
Author

GraanJonlo commented Aug 2, 2021

My situation is that this is used in an asset building pipeline for a legacy project that we have just been keeping ticking over for the last decade. We generally only have to make and deploy a minor change a couple of times a year or sometimes a whole year will go by without any work done on it. The client has no interest in spending money updating the build pipeline and since it's not facing the world the security issues with running such an old version of Node carry less weight with said client.

Obviously in my instance I've just been able to pin to the previous version and cursed whoever came before me for not including the package lock in the repo which would have avoided all this. It's an hour of my life I won't get back but c'est la vie. I'm more raising this issue because someone somewhere will be stuck in a situation where they can't so easily resolve it or they lack the technical know how to figure out why stuff's stopped working.

@vNNi
Copy link

vNNi commented Aug 5, 2021

I'm on same scenario... legacy project who we just do one commit every 2 months, but unfortunately some deps was installed with ^ symbol and yesterday breaks your pipeline.
So, to adjust, i added manually the fixed versions who depends on jpeg-js, and their dependencies too.

dependencies: {
    "get-pixels": "3.3.2",
    "save-pixels": "2.3.0",
    "jpeg-js": "0.3.0
  }

@ericblade
Copy link

But I wonder: Do people really still use Node.js 6 today

There are devices out there in the world that run Node <4.0 still. There are people developing software for those devices still.
That is not a relevant question -- bumping the major version is the correct thing to do. jpeg-js should've updated their major version, and if get-pixels took it, then so should get-pixels.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants