(M)  s i s t e m a   o p e r a c i o n a l   m a g n u x   l i n u x ~/ · documentação · suporte · sobre

 

Software Release Practice HOWTO

Eric Steven Raymond

Thyrsus Enterprises

    esr@thyrsus.com
    

Copyright © 2000 by Eric S. Raymond

Revision History
Revision 3.122 February 2001Revised by: esr
LDP Styleguide fixes.
Revision 3.012 August 2000Revised by: esr
First DocBook version. Advice on SourceForge and a major section on documentation practice added.

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 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 project- and archive- naming practice
2.1. Use GNU-style names with a stem and major.minor.patch numbering.
2.2. But respect local conventions where appropriate
2.3. Try hard to choose a name prefix that is unique and easy to type
3. Good licensing and copyright practice: the theory
3.1. Open source and copyrights
3.2. What qualifies as open source
4. Good licensing and copyright practice: the practice
4.1. Make yourself or the FSF the copyright holder
4.2. Use a license conformant to the Open Source Definition
4.3. Don't write your own license if you can possibly avoid it.
5. Good development practice
5.1. Write either pure ANSI C or a portable scripting language
5.2. Follow good C portability practices
5.3. Use autoconf/automake/autoheader
5.4. Sanity-check your code before release
5.5. Sanity-check your documentation and READMEs before release
6. Good distribution-making practice
6.1. Make sure tarballs always unpack into a single new directory
6.2. Have a README
6.3. Respect and follow standard file naming practices
6.4. Design for Upgradability
6.5. Provide RPMs
7. Good documentation practice
7.1. Good practice in the present
7.2. Good practice for the future
8. Good communication practice
8.1. Announce to c.o.l.a and Freshmeat
8.2. Announce to a relevant topic newsgroup
8.3. Have a website
8.4. Host project mailing lists
8.5. Release to major archives
9. Good project-management practice
  Next
  Introduction

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. ... ... ... ... ... ... ... ... .................................................

Todas a marcas e direitos autorais desta página são de propriedade de seus autores e/ou detentores de direitos.
Copyright © 1998-2003 Flávio Veloso. Todos os direitos reservados. All rights reserved.
Linux é marca registrada de Linus Torvalds. Magnux Linux é marca registrada de Flávio Veloso.