Thanks for raising @mhogara. I agree that if the release breaks support for a given node version that ideally it should be a major release. However I'm not sure how feasible that is in practice. Support for node 16 ended almost 2 years ago. The pipelines for this project test against the current LTS (20) + the previous LTS (18). I could include even the previous LTS (16) which would have caught this breaking change, but then someone would probably raise an issue saying I broke something with node 14. My point is I'm not sure how feasible it is for any maintainer to support X unsupported node versions. Let me know your thoughts

I think it makes no sense from the side of the project to support a version that is EOL 2 years ago.
However, I agree that in the future we should call out changes to minimum supported Node versions in release notes, assuming these were conscious decisions and we are aware of them.

In addition, I think it would also make sense to clearly document, that a minimum Node version 18 is required (basically the lower bound of what we have in CI).

Thank you for the quick response @cristianrgreco , @kiview. I agree with the sentiment here- as a TLDR: it's very sensible to not support EOL versions of Node, but documentation/some announcement of removal of Node support would be great.

I understand that maintaining/running tests against Node16 or any unsupported node version isn't a good use of time, especially given that the EOL isn't recent.

That being said, it would benefit the user to have a clear documentation on what versions of Node are supported or not. The issue here really isn't the fact that testcontainers-node doesn't work on Node16, it's the fact that it happened in a minor version and AFAIK there is not documentation/explicit mention in the release notes that this will happen. The best I could find is this PR: https://github.com/testcontainers/testcontainers-node/pull/675/files where it's taken out of the test runs. Personally, I'd be thrilled to see a minimum requirements page somewhere that lists explicitly what versions are needed of any dependencies. I'm working across a lot of environments, so it's a lot easier when I have something I can reference for weird errors.

Going forwards I think we can do the following:

1. Bump the node engine requirement from 10 (😅) to 18 and publish a major release.
2. Ensure that our pipelines test against the minimum node engine requirement (currently is the case).
3. Do not remove node versions as was done in Retire Node 16 (End-of-life) from CI #675 from our pipelines without updating the engine requirement.
4. Changes to the node engine requirement require a major release.

I hear what you say in terms of documentation, but it wouldn't have helped in this case (you would have read that we support node 16 when you first added testcontainers-node, and then one day it stops working). Whereas following the steps above we'd ensure we follow semantic versioning and then this scenario wouldn't happen in the first place.

What do you think / anything else to add?

@cristianrgreco The plan you outlined sounds great! 👏🏼 I have no flags or additional comments.