Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This, remaining on a known-good release is a form of technical debt to use judiciously and pay down when more convenient. Beta testing everything immediately can be a favor to the community, but it’s probably not your main job.


Actually, it's the opposite in my experience. Beta testing is typically done when most software is released. Basically, at that point your technical debt is all the known & fixed issues that you still have, the features you don't have access to and can't benefit from, the performance issues you still have, the newly deprecated APIs that you are still using, etc. Opting into all that without good reason is a bad idea. If you are afraid things will break, the best way to find out is to just try it. Worst case you have to roll back a change. But at least then you know and you can plan a fix. IMHO anything that isn't on a current version should have a documented reason why that is or be fixed ASAP. I rarely see this on projects. Usually that means nobody cared enough to try which is just a form of negligence.

On most of my projects I update dependencies whenever I can. On my older projects, I don't even touch any source code until after I update dependencies whenever I do maintenance on them. Typically either nothing breaks, I need to do some minor fixes, or I need to temporarily roll back some dependency to plan some bigger change. The thing is, if a new version is going to require any kind of non trivial work, I want to know about this as early as possible; especially if it is a lot of work. If you wait a year, you are looking at a lot of unknown work, which is basically technical debt you did not even know you had. I don't like that kind of uncertainty.

Mostly staying on top of things minimizes the work you actually have to do. And you get to benefit from all the fixes early. A lot of projects I join are hopelessly outdated. It's usually the first thing I fix. It's rare to find documented reasons why a particular thing can't or shouldn't be updated. If it's not documented, I'm just going to go ahead and fix it. In case it doesn't work, I'll document it.


> If you are afraid things will break, the best way to find out is to just try it.

How much of the team is awake, sober, and on the grid at that moment? Some times are worse than others for an outage.


Shouldn’t need to be anyones job. Automate:

Daily chron:

- Branch the repo, auto-update one dependency (ideally a smarter way to batch up groups)

- Run CI

- Auto-merge commit if CI passes, else discard commit.

- Loop to create a new branch for the next dependency waiting to be auto-updated.

Otherwise, not having the right testing or CI is technical debt like the grand parent commenter suggests.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: