Software Release Practice HOWTO
Eric Steven Raymond
Copyright © 2000 Eric S. Raymond
| Revision History | ||
|---|---|---|
| Revision 4.1 | 2013-01-14 | Revised by: esr |
| Check out from a repo to be sure of making patches against fresh code. Freshmeat changed its name. USENET topic groups aren't very visible any more. | ||
| Revision 4.0 | 2010-04-11 | Revised by: esr |
| It's no longer necessary to provide RPMS or debs at project level. The packaging infrastructure has gotten good at that. New caveats about configuration and autotools. AsciiDOC is now a viable alternative for documentation masters. | ||
| Revision 3.9 | 2004-11-28 | Revised by: esr |
| New material on good patching practice. Recommend Electric Fence and valgrind rather than proprietary tools. | ||
| Revision 3.8 | 2003-02-17 | Revised by: esr |
| URL fixups after site move. | ||
| Revision 3.7 | 2002-09-25 | Revised by: esr |
| Point at the DocBook Demystification HOWTO. | ||
| Revision 3.6 | 2002-09-12 | Revised by: esr |
| Incorporated material on portability by Keith Bostic. | ||
| Revision 3.6 | 2002-08-14 | Revised by: esr |
| Rewrote section on documentation practice, since XML-Docbook is mature now. | ||
| Revision 3.5 | 2002-07-04 | Revised by: esr |
| Added section on providing checksums. Cited doclifter. | ||
| Revision 3.4 | 2002-01-04 | Revised by: esr |
| More about good patching practice. | ||
| Revision 3.3 | 2001-08-16 | Revised by: esr |
| New section about how to send good patches. | ||
| Revision 3.2 | 2001-07-11 | Revised by: esr |
| Note about not relying on proprietary components. | ||
| Revision 3.1 | 2001-02-22 | Revised by: esr |
| LDP Styleguide fixes. | ||
| Revision 3.0 | 2000-08-12 | Revised by: esr |
| First DocBook version. Advice on SourceForge and a major section on documentation practice added. | ||
This HOWTO describes good release practices for Linux and other 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 it.
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.