Different people seem to go with vastly different release strategies for software. When and how often you release has knock on affects on how you test and how you develop or consider new features.
- Releasing a new version of your software is fast and easy.
- Downloading an updated version of your software is fast and easy.
Both these points should almost always be under your control. If they aren't true, do everything in your power to make them true. If you're going through an App Store, point 2 should be implicitly true. Point 1 is usually true in that submitting is pretty quick and easy. It might take a few weeks to actually get reviewed and published, but there's nothing to stop you following up with a new release in the mean time: it's a pipeline.
If you manage the whole software stack, make downloading updates fully transparent (think Google Chrome). If it's a library, then use and rely on SemVer. Make uploading a new version a single command line message: foo publish v1.0.0
The problem with frequent releases is that it's difficult to prevent bugs slipping into your software. You can help that with automated tests. A module is never finished unless it has a series of automated tests. I don't care how big or small your software product is; running a manual test twice is doing it wrong (Golden Rule No. 1).
Some things are legitimately difficult to test. If you have a complex project run on many platforms in many different situations there will be bugs slipping through the cracks. People try and solve this by making the release cycles longer to allow for more time to test. The issue is, it still allows bugs through the cracks. Unless your software bugs might cost lives (or millions of dollars) people will forgive the occasional bug. In fact, they'll forgive a lot of bugs, provided those bugs are fixed quickly.
Always fix bugs before writing new features (Golden Rule No. 2). This is important for multiple reasons. Nothing will annoy your users more than having something that doesn't work remain broken while being told about exciting new features they're not going to use.
Users will also normally forgive bugs if they know that releases typically come out every few days and always fix bugs before adding features. This brings me to my closing argument.
Someone is always waiting for your bug fix or new feature. If you wrote code this week, you should be planning to release this week (Golden Rule No. 3).