Skip to main content

When to release.

Posted by richburridge on May 12, 2004 at 8:39 AM PDT

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.
Related Topics >>