No doubt you’ve heard the maxim “release early, release often.” It’s one of the cornerstones of Free/Open Source software development. By making frequent releases, you give your users the opportunity to try out the new features and tell you what they think of them. By showing people what you’re working on, you have the opportunity to adjust it as you go, rather than getting to the end of the road and discovering that nobody wants to go there.
But how often is often enough? Is it possible to release too often?
When evaluating a project to see if it’s one I want to adopt, I consider several factors. One of the top factors is the date when the project was last updated. This gives me a sense of whether the project is active, which, in turn, gives me some idea of what I can expect with regards to product support and longevity.
If a project has regular releases, and has had for a while, I think maybe I can expect them to continue into the future. On the other hand, if the last release was five years ago, I don’t even bother to evaluate the product, because I know that my support requests are going to go unanswered.
Frequent releases, particularly with detailed release notes, tell the users that the product is making steady progress, and that user feedback is being heeded. It tells the user that if they make a request, or file a bug, it’s not going into a void, but that there will eventually be a release that addresses their concern.
And, in turn, the impression that is created of a vibrant and active project brings not only new users, but new developers.
So, when should you release? The easy answer is “when it’s ready,” but this depends largely on the nature of your project.
If your product is a low-level developer-focused thing like a Perl module or a C library, any time it passes all of the tests (you do have tests, right) ship it. Developers want the latest and best thing you have available. On the other hand, if it’s a desktop product with a polished user interface, a new release should probably include some change or feature that the end-user is actually going to notice, otherwise they’ll decide there’s no value in getting updates.
We recommend you cut a new release any time there’s something new that might benefit the end-user. This might be a bug fix, a completed new feature, or an enhancement to an existing feature. When the coding is complete and the change has been tested, there’s no reason to withhold it from the customer. Ship it, and let them experience the new shine.
There are, of course, complications to this. You may be working on several things at once, and one is complete while another is still in progress. Or perhaps several features enhance one another in such a way that it makes sense to push them out together. Just make sure you have a good reason for not releasing.
Finally, there’s the question of whether you can release too often. I think you can. Releasing too often has two side-effects.
One, it gives the impression that you don’t think very hard before releasing. This, in turn, makes people concerned about the quality of your releases. Be sure that a release works and is thoroughly tested, before pushing it out.
Second, if there’s a release every day, you eventually train people that there’s no real value in getting every update. This causes problems when a release is critical, such as an important bug fix or security patch.
It’s a good idea to ask your users how often they expect releases. Listening to your customers is always a good idea.