But, obviously, security updates are an exception. I think this needs to be a disclaimer on the top of the article, not a single line in the end. Really.

By staying a few version numbers behind the bleeding edge, you enable other, braver souls to clear the way.

I think you should clarify that you mean major and minor versions (in terminology of semver, i.e. major.minor). Patch releases often fix the bugs or security issues, you should be fine if project adheres to semver.

Also, for “bleeding edge” there are alpha and beta releases, as well as release candidates. The less people gonna check that it works beforehand with their apps, the more there will be situations when almost right after a major/minor release there is a series of patch releases.

It works even for a widely-used project like Rails - consider what the blog post about rc for 5.1 (http://weblog.rubyonrails.org/2017/3/20/Rails-5-1-rc1/) says: > Please help us test this release candidate version of Rails. It’s always frustrating when we put a lot of work into a new release, betas, release candidates, and then get people report all sorts of issues on week one of the final release. This is an incremental upgrade to Rails 5.0. Please do your community duty and help us land a solid 5.1 without needing an immediate 5.1.1.

hey Ivan–only seeing your feedback now sorry. You’re absolutely 100% right about the need for me to place more emphasis on the fact that security is exceptional. Gonna modify it now.