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.
Next |
Introduction |