Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
International Rescue Committe

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
Copyright Info
Terms of Use
Privacy Info
Masthead / Impressum
Your Account

Private Messages

News Archive
Submit News
User Articles
Web Links


The Web

Who's Online
There are currently, 219 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here



Current HOWTO: Software-Release-Practice-HOWTO

Software Release Practice HOWTO

Software Release Practice HOWTO

Eric Steven Raymond

Thyrsus Enterprises


Revision History
Revision 3.42002-01-04Revised by: esr
More about good patching practice.
Revision 3.32001-08-16Revised by: esr
New section about how to send good patches.
Revision 3.22001-07-11Revised by: esr
Note about not relying on proprietary components.
Revision 3.12001-02-22Revised by: esr
LDP Styleguide fixes.
Revision 3.02000-08-12Revised 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
1.1. Why this document?
1.2. New versions of this document
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 RCS or SCCS $-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
3. Good project- and archive- naming practice
3.1. Use GNU-style names with a stem and major.minor.patch numbering.
3.2. But respect local conventions where appropriate
3.3. Try hard to choose a name prefix that is unique and easy to type
4. Good licensing and copyright practice: the theory
4.1. Open source and copyrights
4.2. What qualifies as open source
5. Good licensing and copyright practice: the practice
5.1. Make yourself or the FSF the copyright holder
5.2. Use a license conformant to the Open Source Definition
5.3. Don't write your own license if you can possibly avoid it.
6. Good development practice
6.1. Write either pure ANSI C or a portable scripting language
6.2. Don't rely on proprietary code
6.3. Follow good C portability practices
6.4. Use autoconf/automake/autoheader
6.5. Sanity-check your code before release
6.6. Sanity-check your documentation and READMEs before release
7. Good distribution-making practice
7.1. Make sure tarballs always unpack into a single new directory
7.2. Have a README
7.3. Respect and follow standard file naming practices
7.4. Design for Upgradability
7.5. Provide RPMs
8. Good documentation practice
8.1. Good practice in the present
8.2. Good practice for the future
9. Good communication practice
9.1. Announce to c.o.l.a and Freshmeat
9.2. Announce to a relevant topic newsgroup
9.3. Have a website
9.4. Host project mailing lists
9.5. Release to major archives
10. Good project-management practice

The Linux Tutorial completely respects the rights of authors and artists to decide for themselves if and how their works can be used, independent of any existing licenses. This means if you are the author of any document presented on this site and do no wish it to be displayed as it is on this site or do not wish it to be displayed at all, please contact us and we will do our very best to accommodate you. If we are unable to accommodate you, we will, at your request, remove your document as quickly as possible.

If you are the author of any document presented on this site and would like a share of the advertising revenue, please contact us using the standard Feedback Form.




Security Code
Security Code
Type Security Code

Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!

Amazon Wish List

Did You Know?
The Linux Tutorial can use your help.


Tell a Friend About Us

Bookmark and Share

Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.11 Seconds