I'm not a fan of blindly updating; I'd rather read the changelogs and decide if I need to update or not, but I sort of understand the utility of it. Most testing happens against the latest release version or HEAD in version control. If the version you're running has different behavior than those two versions and the change wasn't well documented, and the behavior in your version is problematic, it's not likely that other people will discuss it and call your attention to it. Even if people run into that bug, they may just update and move on, rather than post about it being broken.<p>Depending on the project, and the changes involved, sometimes it's beneficial to upgrade frequently and make required integration changes in small increments rather than say once a year with a big change. Sometimes, it's much worse to follow the changes; some projects churn <i>a lot</i> and integration changes are kind of fixed per release, letting releases pile up means less overall work in that case.<p>Also, if you get support from upstream (which IMHO is a big if), they'll tend to prefer for you to be working on a current version. You tend not to get much support when you're running older versions. OTOH, I'm not used to having a support workflow. It's often too hard to engage with external developers, so either the external software works, or you make changes so it works, without discussing with upstream.