- Best practice for both reliability and security is to not immediately upgrade to latest versions. Only immediately upgrade to security-patched versions. If your software doesn't need a new version, you can remain on the old version.

- When a feature you're developing, or a transitive dependency, requires an upgraded version, you can upgrade to the latest stable version that satisfies the dependency. But as each of those then requires an additional transitive dependency to be upgraded, you have more and more components upgraded to "latest", and the attack surface widens. So there are two alternatives:

1) (preferred) Upgrade to the latest version of the next-to-latest minor version, within the oldest major version that is supported, if that is available. This is the least number of changes that provides the needed functionality.

2) Upgrade only to the oldest version that gives you the functionality you need. If this ends up being the first version of a new major or minor version, this can cause bugs (initial releases of new major/minor always has bugs), so in that case you might as well use the latest version of that major/minor version.

This all affects security by avoiding upgrading to the latest version. It affects reliability by minimizing the amount of changes between your current version and upgraded version (changes lead to bugs).

The argument against all that, and for always upgrading to the latest versions, is intended to make software development easier. You avoid all the complexity of picking versions or reading changelogs by using software that is probably (but not always) all compatible. But it makes reliability and security worse. So you need to choose: do you want security and reliability, or an easier time writing code?