Here are a few comments and thoughts on various aspects of doing a new release of an open source project. They might not all apply to each project. They might all be obvious. I'm just throwing them out there. Some of these are rules that I've been applying to my open source projects for the last 19 years. Others are from working with the GNOME folks. Others are from integrating software into the Solaris O/S.

How often should you release? I see a lot of small projects seemingly doing a new release every few days with minimal changes between each release. Although open source developers are encouraged to release "early and often" there are various things to be taken into consideration when you do this:

• What extra value are you providing in this new version that would make the potential user want to rush out and install it?
• How complicated is the install process? If it's not straight forward (i.e. if there are a lot of things that don't happen automatically by default), then users will be hesitant to continually upgrade.
• How easy is it to go back to a previous version if the latest version proves to be unusable?

If you are part of a larger open source project (like KDE or GNOME for example), then you will have to make sure that you also fit in with their release process. You'll still do your own project releases, to get new versions "out there" to be tried, but you will also be aiming to have a certain amount of work fully completed by the time that the larger project is ready to ship.

If you are part of a bigger release, then there will be other deadlines that you will have to abide by:

• Feature freeze - when the last new features can be added.
• UI freeze - when the last user interface change can be made. This is typically to allow the folks that are writing the user documentation and online help to do their work.
• Strings freeze - when text strings are frozen, so that translators can get busy translating your project into other languages.
• Bug freeze - no more bug fixes beyond this point, unless they are show-stoppers.

Following guidelines like these will instill good discipline, even if you are not part of a bigger project.

What should be in a new release? Sometimes it's hard to know exactly what you should put in a new release and what you should leave out. Here are a few suggestions that will hopefully help you decide.

• Listen to what your users are telling you. If they have a particular feature request or many of them are complaining about a particular problem, adding this new feature or fixing that bug this should be one of your top priorities for the next release.
• Try to assign a priority and severity value to each of the bugs or requests for enhancement that have been reported against your project and work on fixing the ones with the highest value first. There is a tendancy to "cherry pick" the easiest ones to implement. If you have limited time you should be concentrating on the important ones.
• If you are still unsure, and you know who your users are (i.e. you have something like a mailing list for your project) then consider providing a list of possibilities to your users and asking for them to vote on what they would like to see be done.