There are the releases you plan and the releases you don't. The releases you plan usually have nice numbers like "3.2" and "10.6". The ones you don't usually have names like "patch 2010.02.12". Patches are often a reaction to surprise. They're a quick enhancement that sales Really Truly Needs to close a deal this quarter. They're a bug fix for something you thought you'd tested for but apparently missed. They're a bug fix for something you totally never expected in a million years but that hit a major customer.
It's difficult to know what will trigger the need for a patch, since it's different each time. However, it's not nearly as difficult to know that you will need a patch. You can't say what's in it, but you can definitely say you'll need it. Think back over your last three minor releases? How many of them also had patch releases later? How many patches between a minor release and the next release? Now repeat for major releases. For this purpose, consider "major" to be a release with a lot of new things and/or change in it. Consider "minor" to be a release with a relatively small amount of new things. This may or may not map with what marketing wound up calling a major release or a minor release.
Usually, you'll find that big releases where you introduced a lot of new stuff have the most patches after them. Minor releases have fewer patches after them. It'll look something like this:
It's easy to think of patch releases as surprises, but really, they're like birthday presents. You know you're going to get some; you just don't know what will be in them. So plan ahead and leave yourself room in your schedule for a patch release. After all, it's coming.