Posted by richburridge
on May 12, 2004 at 8:39 AM PDT
Some thoughts on various things related to the release process for open source projects.
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
- 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
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
- 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.