Software Release Practice HOWTO
Eric Steven Raymond
Copyright © 2000 Eric S. Raymond
| Revision History | ||
|---|---|---|
| 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 fr 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.
- Table of Contents
- 1. Introduction
- 2. Good patching practice
- 2.1. Do send patches, don't send whole archives or files
- 2.2. Send patches against the current version of the code.
- 2.3. Don't include patches for generated files.
- 2.4. Don't send patch bands that just tweak version-control $-symbols.
- 2.5. Do use -c or -u format, don't use the default (-e) format
- 2.6. Do include documentation with your patch
- 2.7. Do include an explanation with your patch
- 2.8. Do include useful comments in your code
- 2.9. Just one bugfix or new feature per patch.
- 3. Good project- and archive- naming practice
- 4. Good licensing and copyright practice: the theory
- 5. Good licensing and copyright practice: the practice
- 6. Good development practice
- 7. Good distribution-making practice
- 8. Good documentation practice
- 9. Good communication practice
- 10. Good project-management practice
| Next | ||
| Introduction |