3 ms·

A project can't be more stable than its dependencies and tooling, but that doesn't mean that the only way to be stable is to have no dependencies. Some program

A project can't be more stable than its dependencies and tooling, but that doesn't mean that the only way to be stable is to have no dependencies. Some programming languages make guarantees that old code will build in new versions (eg, ISO C even refuses to introduce new warnings for code that would previously build without warnings), while others will introduce backwards incompatible changes in minor releases. How much maintenance a project needs after it is "done" really depends on the tooling environment.

scoopertrooper 6y ago
Library and framework maintainers will eventually stop updating previous major versions. So you manage to tread water just fine till your major version reaches EOL, then you've found yourself in the position of having to change over to a completely new API on a schedule set by the maintainer of the dependency.
- hdjdbtbgwjsn 6y ago
  It depends on the language. Fortran last broke backwards compatibility with F90. F77 code is still 100% supported. C is similar.
  - pas 6y ago
    As far as I know Java too. That doesn't mean it's still best practice to write code that uses unsafe/deprecated constructs.
- dragonwriter 6y ago
  > Library and framework maintainers will eventually stop updating previous major versions. And, if it's open source and it's easier than switching to a new dependency, you can just adopt maintenance of the dependency—not necessarily generally, just enough to address any bugs induced in or evolution in needs for the project(s) you have that depend on it.
dragonwriter 6y ago
> A project can't be more stable than its dependencies Sure it can; there's no reason a project has to take every upstream update, if, for instance, it vendors dependencies, or otherwise doesn't directly depend on the remotely maintained source.
- pas 6y ago
  Someone has to mull over whether to apply the update or not. Usually this is a by default "not" for most projects. (And that's not necessarily a bad stance.) Stability is great as long as you have the luxury of no pressure for new features or better security. (Eg. operating systems, browsers, compilers, critical libraries don't.)

scoopertrooper 6y ago

Library and framework maintainers will eventually stop updating previous major versions. So you manage to tread water just fine till your major version reaches EOL, then you've found yourself in the position of having to change over to a completely new API on a schedule set by the maintainer of the dependency.

hdjdbtbgwjsn 6y ago
It depends on the language. Fortran last broke backwards compatibility with F90. F77 code is still 100% supported. C is similar.
- pas 6y ago
  As far as I know Java too. That doesn't mean it's still best practice to write code that uses unsafe/deprecated constructs.
dragonwriter 6y ago
> Library and framework maintainers will eventually stop updating previous major versions. And, if it's open source and it's easier than switching to a new dependency, you can just adopt maintenance of the dependency—not necessarily generally, just enough to address any bugs induced in or evolution in needs for the project(s) you have that depend on it.

dragonwriter 6y ago

> A project can't be more stable than its dependencies Sure it can; there's no reason a project has to take every upstream update, if, for instance, it vendors dependencies, or otherwise doesn't directly depend on the remotely maintained source.

pas 6y ago
Someone has to mull over whether to apply the update or not. Usually this is a by default "not" for most projects. (And that's not necessarily a bad stance.) Stability is great as long as you have the luxury of no pressure for new features or better security. (Eg. operating systems, browsers, compilers, critical libraries don't.)