Remix.run Logo
plomme 3 hours ago

Why not take it further and not update dependencies at all until you need to because of some missing feature or systems compatibility you need? If it works it works.

skybrian 3 hours ago | parent | next [-]

The arguments for doing frequent releases partially apply to upgrading dependencies. Upgrading gets harder the longer you put it off. It’s better to do it on a regular schedule, so there are fewer changes at once and it preserves knowledge about how to do it.

A cooldown is a good idea, though.

kunley 2 hours ago | parent | prev | next [-]

> Why not take it further and not update dependencies at all until you need to because of some missing feature or systems compatibility you need? If it works it works.

Indeed there are people doing that and communities with a consensus such approach makes sense, or at least is not frowned upon. (Hi, Gophers)

SkyPuncher 2 hours ago | parent | prev | next [-]

This works until you consider regular security vulnerability patching (which we have compliance/contractual obligations for).

bigstrat2003 2 hours ago | parent | prev | next [-]

That is indeed what one should do IMO. We've known for a long time now in the ops world that keeping versions stable is a good way to reduce issues, and it seems to me that the same principle applies quite well to software dev. I've never found the "but then upgrading is more of a pain" argument to be persuasive, as it seems to be equally a pain to upgrade whether you do it once every six months or once every six years.

jonfw 2 hours ago | parent | prev | next [-]

There is a Goldilocks effect. Dependency just came out a few minutes ago? There is no time for the community to catch the vulnerability, no real coverage from dependency scans, and it's a risk. Dependency came out a few months ago? It likely has a large number of known vulns

yupyupyups an hour ago | parent | prev | next [-]

Just make sure to update when new CVEs are revealed.

Also, some software are always buggy and every version is a mixed bag of new features, bugs and regressions. It could be due to the complexity of the problem the software is trying to solve, or because it's just not written well.

tim1994 2 hours ago | parent | prev | next [-]

Because updates don't just include new features but also bug and security fixes. As always, it probably depends on the context how relevant this is to you. I agree that cooldown is a good idea though.

ryandrake 2 hours ago | parent | next [-]

> Because updates don't just include new features but also bug and security fixes.

This practice needs to change, although it will be almost impossible to get a whole ecosystem to adopt. You shouldn’t have to take new features (and associated new problems) just to get bug fixes and security updates. They should be offered in parallel. We need to get comfortable again with parallel maintenance branches for each major feature branch, and comfortable with backporting fixes to older releases.

tshaddox 27 minutes ago | parent | next [-]

Are you just referring to backporting?

nine_k an hour ago | parent | prev [-]

Semver was invented to facilitate that. Only if everyone adhered to it.

ghurtado 16 minutes ago | parent [-]

> Semver was invented to facilitate that

First time I've heard that. How does semver facilitate backporting?

theptip 2 hours ago | parent | prev | next [-]

IMO for “boring software” you usually want to be on the oldest supported main/minor version, keeping an eye on the newest point version. That will have all the security patches. But you don't need to take every bug fix blindly.

YouAreWRONGtoo an hour ago | parent [-]

[dead]

shermantanktop 2 hours ago | parent | prev [-]

For any update:

- it usually contains improvements to security

- except when it quietly introduces security defects which are discovered months later, often in a major rev bump

- but every once in a while it degrades security spectacularly and immediately, published as a minor rev

an hour ago | parent | prev [-]
[deleted]