You shouldn’t fear changing your code, who else will change it if you won’t out of fear?
Change, after change, after change. Isn’t software just done after some point? The set of responsibilities the software has moves around. There seems to be a temptation to make software be more and do more, all while reducing its lifetime by hackjobs.
Even software that doesn’t change in the source code, it still rots. The language its source code is in, how known the software is and the users that actively use it; they can all decline as the software gets older.
It is all replaceable and updateable, by developers that change in their preference. The same software can keep on existing in other forms; by being rewritten in other programming languages according to the original as the specification. If the software you build is still not done, and needs the support from the new features of the dependencies, then you should adapt to the larger shifts in ecosystems that developers work in and libraries exist for. If the software you build is already done, it would only need to if the ease of installation and ease of using it as a dependency is at risk; That is, if you still want active use. If none of the above apply, software can serve as inspiration in the current form, even when it doesn’t compile anymore. The source code can tell the story, and it becomes a part of history.
So would you consider changing the programming language of your project. Or does that feel the same like distro-hopping, where it only affects the starting-conditions? It doesn’t have to feel that way, as the old and new languages can co-exist. Bonus points if the newer languages transpiles to the old one, or any bytecode that the old one uses. It allows to use the old ecosystem as a stable base, incrementally update the old code where needed, and have an present day advanced ecosystem to work in for the new code. This made me go back to Java land, JVM languages take advantage of the decades used to build the Java ecosystem.