Software Release Practice HOWTO

Eric S. Raymond <esr@thyrsus.com>

1.0, 21 November 1998

This HOWTO describes good release practices for Linux open-source projects. By following these practices, you will make it as easy as possible for users to build your code and use it, and for other developers to understand your code and cooperate with you to improve. This document is a must-read for novice developers. Experienced developers should review it when they are about to release a new project. It will be revised periodically to reflect the evolution of good-practice standards.

1. Introduction

1.1 Why this document?
1.2 New versions of this document

2. Good project- and archive- naming practice

2.1 Use GNU-style names with a stem and major.minor.patch numbering.
2.2 Try hard to choose a name prefix that is unique and easy to type

3. Good development practice

3.1 Write either pure ANSI C or a portable scripting language
3.2 Follow good C portability practices
3.3 Use autoconf/automake/autoheader
3.4 Sanity-check your code before release

4. Good distribution-making practice

4.1 Make sure tarballs always unpack into a single new directory
4.2 Have a README
4.3 Respect and follow standard file naming practices

5. Good communication practice

5.1 Announce to c.o.l.a
5.2 Announce to a relevant topic newsgroup
5.3 Have a website
5.4 Host project mailing lists
5.5 Release to major archives
5.6 Provide RPMs