When committing to a piece of software, favor those created by people who value backward compatibility.
By “piece of software,” I mean any source code dependencies (libraries, frameworks), runtime dependencies (e.g., databases, web servers), or tools (e.g., editors).
Different projects have different cultures of preserving the stability of programmable interface, user interface, and default behavior.
Why should you care?
Stable software is less work down the road when it comes to upgrades.
Stable software is better understood. Documentation and third-party guides will stay relevant longer; lessons learned will remain valuable. Trade-offs are acknowledged.
Third-party plugins will keep working.
It is probably tested better.
If you have to deal with an older version (e.g., because you are restricted by repositories available on production servers, or you have to downgrade for security reasons), you’ll stuff will still work fine. Also see: Would your code work after a trip back in time?
Many of these aspects have characteristics of compound interest; if the community around software can safely assume that their guides and plugins will stay relevant, its members are more likely to contribute.
How to tell if a piece of software is likely to remain stable?
Age. If a piece of software is old but still in active use and maintenance, it is more likely that its creators got something right and kept it stable.
Marketing copy. Look at the project’s website; sometimes projects are explicit in what they value, and it is not always the stability.
Size and scope. The larger the scope, the harder it will be to remain stable.
Version history. For projects using SemVer, frequently changing major version numbers is an obvious red flag. Note that many old, stable projects don’t use SemVer.
Upgrade guides. If they are long complicated, beware. But, of course, a total lack of upgrade guides is not a good sign, either.
Of course, there is a flip side; you do miss on bleeding edge. But it’s OK – just because something is newer does not automatically make it good.
I’m surprised that more people don’t consider stability when picking dependencies. I would be more understanding of people who were consciously choosing projects that don’t value stability. Still, many times when I see somebody picking a new library, they don’t even try to estimate how stable it is.
Even when using a stable project, don’t rush to get dependent on the latest features because they are less likely to be stable, well understood, or available if you are forced to use an older version.
And one final piece of advice: don’t ever let your career depend on an unstable platform and tooling unless you directly profit from that instability.