1. Introduction 1.1 Why does this document exist? 1.2 New version of this document 2. Good engineering naming practice and archive (Archive) Naming Customs 2.1 Put the name of the GNU style for the word dry (STEM) and Major.minor.Patch encoding. 2.2 But at the appropriate time to respect the original habits 2.3 try to choose a unique and easy-to-entered name prefix 3. Good license and copyright formula: Theory 3.1 Open source code and copyright 3.2 open source should be applied What restrictions (Qualifies) 4. Good license and copyright practice: Practice 4.1 Make yourself or Free Software Foundation (FSF) becomes copyright owner 4.2 Use licenses that meet open source code 4.3 as long as it may be avoided, don't Write your own license. 5. Good Development Formula 5.1 Coding 5.2 Observing Class 5.3 Using AutoConf / Automake / AutoHeader5.4 Using AutoConf / Automake / AutoHeader5.4 Using AutoConf / Automake / AutoHeader5.4 Publish your code ( Sanity-Check) 6. Good release creation practice 6.1 Make sure the TAR package always opens to a separate new directory 6.2 containing a readme6.3 respect and obey the standard file naming practice 6.4 Provides RPMS7. Good communication practice 7.1 in COLA Notice 7.2 Notification in the relevant topic newsgroups 7.3 Having a website 7.4 Sub-mail 7.5 Released to the main archive 8. Good engineering management
1. Introduction 1.1 Why does this document exist? There are many good practice traditions that help others transplant, use and cooperate development. Part of these habits is the tradition of the UNIX world and appears before Linux; other new tools and technologies, such as the Internet, such as the Internet (World Wide Web). This document will help you learn well. It organizes according to the subject, and each topic contains an entry for checklist. Give these entries as an entry that you need to check before you release it. 1.2 New Version of this document This document will be sent to the newsgroup in the newsgroup in the newsgroup. This document has been archived on many Linux FTP stations, including Metalab.unc.edu, on Pub / Linux / DOCS / HOWTO. You can also access the latest version of this HOWTO through the Internet URL below. Http://metalab.unc.edu/ldp/howto/software-release-practice.html. Please send any questions about this howto or recommendation to Eric S. raymond, esr@snark.thyrsus.com . -------------------------------------------------- ------------------------------ 2. Good engineering naming practice and archive (Archive) naming customs with these, such as Metalab, The PSA site and the workload of the CPAN archive maintenance are increasingly tended to process a part or all work (not completely someone complete). This makes the name of the engineering and archive files that comply with computer programs to parse and understand. 2.1 Use the name of the GNU style for the word dry (STEM) and Major.minor.Patch encoding. If your archive file uses a name similar to the GNU - all of the stems of lowercase letters and numbers, followed by horizontal lines, and then the version number, extension, and other suffixes, it is helpful for everyone. Let us assume that you have a project called `foobar 'is 1st, the second release, Level 3. If it has only one archive portion (probably the source code), this is the name foobar-1.2.3.tar.gz source code archive FOOBAR.LSMLSM file (assuming you want to submit to MetaLab). Please do not use these names: foobar123.tar.gz For many programs, it looks like a project called `foobar123 'without a version number archive. Foobar1.2.3.tar.gz For many programs, it looks like a project called `foobar1 'and version number is 2.3 project. Foobar-v1.2.3.tar.gz Many programs believe that the project is called `FOOBAR-V1 '. Foo_bar-1.2.3.tar.gz For people, the underscore is difficult to pronounce, enter and remember FOOBAR-1.2.3.tar.gz unless you think you look like a small citizen (Marketing Weenie). For people, it is also difficult to pronounce, input, and memories. If you have to distinguish between source code and binary archives, or distinguish between different types of libraries, or express some creation options in the file name, put them as a file extension in the version number.
That is, this: foobar-1.2.3.src.tar.gz source code FOOBAR-1.2.3.bin.tar.gz binary code, no type foobar-1.2.3.bin.elf.tar.gzelf binary Code foobar-1.2.3.bin.elf.static.tar.gz static connection ELF binary code FOOBAR-1.2.3.bin.sparc.tar.gzsparc binary code Please do not use such as `foobar-ELF-1.2.3. Tar.gz 'The name, this is because the program will encounter difficulties whenfix the type (, such as `-elf') from the word dry. The form of a good general name is in the order: the item prefix horizontal version number "src" or "bin" (optional) point or horizontal (better) binary type and option (optional) Archive and compressed extension 2.2 But respectively respect the original habits (Local Conventions) certain engineering and communities have defined a good practice for the name and version number, which does not have to be compatible with the above recommendations. For example, the Apache module is typically named in the form of mod_foo, as well as their own version number and the version number of Apache. Similarly, the Perl module contains a version number that can be seen as a floating point number (for example, you may see 1.303 instead of 1.3.3), and the release of the module foo :: bar's 1.303 version is usually called Foo-bar-1.303 .tar.gz. Find and respect the habits of specific communities and developers; for general purposes, obey the above guidance. 2.3 Try to choose a unique and easy-to-entered name prefix word, dry prefix is common for files in all projects, and it should be easy to read, input, and memorize. So please do not use underscore. And do not use uppercase or part of the uppercase letters when there is no excellent reason - it will interfere with the search order of human eye and look a bit like a small citizen is smart. When two different engineering use the same word, it will cause confusion. So try your conflict before you first issued. A good place to check is Index file of metalab. 3. Good license and copyright formula: Theory you choose the license to define the social contract you want to set by you and your collaborative developers and users. The copyright you set for the software will mainly play a legal statement for you to set up licenses for your software and from software. 3.1 Open source code and copyright anything that is not a public domain is likely to be more than one copyright. According to the Bern Convention (from 1978, it has become a US in the United States), copyright does not have to be explicitly declared. That is, even if there is no copyright statement, the author of a work still holds copyright. Who is the author, it is very complicated, especially for software that has worked through many people. This is why the license is important. By setting the clause to use those materials, they can authorize the user to protect users when they are alone. In private software, the license terms are designed to protect copyright. They are a way to grant a small number of powers while ensuring most of their legal power while ensuring most legal powers. The copyright owner is very important, and the logic of the license is so strictly that the accuracy of the license terms in technology is not important. In open source software, the situation is usually the opposite; the existence of copyright protection has protected licenses. The only power of the copyright owner is to maintain and enforce the license. Otherwise, only the few power is retained and most of the options are handed over to the user. In particular, the copyright owner cannot modify the terms of the copy you already have.
Therefore, the copyright owner of open source software is almost unrelated - but the license terms are very important. The copyright owner of the project is generally the current leader or organizational initiator of the project. Turn the project to new leaders usually need to mark the copyright owner. However, this is not a difficult and secure rule; many development source code projects have multiple copyright owners, and this record has not happened to lead to a precedent for legal issues. Some software projects choose to give copyright to the Free Software Foundation. In theory, this practice is important for the protection of open resources, and it is also possible to legally. 3.2 Open source should apply what restrictions on licensing, we can divide them into several licenses that can be transferred. Copy the power of re-release, the power used, modified for personal use, and the power to re-release the modified version. The license can limit or add any such rights. Open source code is the result of how to make the software "open source" or (according to past terms) "freedom" thinking. It limits the license: the power must be granted unrestricted replication. The power to be unrestricted use must be granted. It is necessary to grant the power to be modified for personal use. The guideline prohibits the application of two-category code after re-released modification; it meets the needs of software publishers who do not want to have any troubleship of work codes. It allows the author to request the modified source code to add a patch in the form of the patch to ensure the author's intentions and any modified "audit record" made by others. Open Source Code Definition (OSD) is the statutory definition of the 'OSI Certified Open Source' authentication flag, and is a good definition of "free software" that people have proposed. All standard licenses (MIT, BSD, Artistic, and GPL / LGPL) are met (although some, for example, GPL, you should understand it before selecting it). It is worth noting that only a license for non-commercial use is allowed, even if it is decorated with "GPL" or other standard licenses, there is no qualification for open source licenses. They discriminate against specific occupations, individuals and groups. They make people living with people with CD-ROM and other people trying to commercially distributing open source software are too complicated. -------------------------------------------------- -------------------------- 4. Good license and copyright formula: practice here how to make the theoretical practice: 4.1 Make yourself Or the Free Software Foundation (FSF) becomes the owner of the copyright In some cases, if you have a lawyer who supports your initiating organization, you may want to grant copyright to that organization. 4.2 Using the license open source code defined by the open source code is the gold public standard set for the license. OSD itself is not a license; in contrast, in order to confirm a development source code license, OSD defines the minimum collection of powers that must be ensured by the license. OSD and support information can be found on the website open source. 4.3 As long as you may be avoided, don't write your own license. It is well known that obey the license from OSD has a good definition formula. Developers (and their concern, users) know what it means, and has reasonable feelings for their risks and trading they involve. Therefore, as long as it is possible, use a standard license obtained from OSI. If you have to write your own license, please confirm that it gets the authentication of OSI. This will avoid a lot of debate and spending.
Unless you have already considered, you will not understand how much a license will lead to how much threat; because the license is seen as a similar approval of the core values of the open source community, people thus become full of enthusiasm. . Further, if your license has been inspected in court, it confirms the importance of the existence of explanatory practices. When writing this article (1999's recent), there is no legal case that supports or opposes any open source licenses. However, it is a legal literature that will be explained in accordance with the expected intentations and the Practice of the Social Squiries (at least in the United States, and other places such as England and British federal, ordinary laws. The country is like this). -------------------------------------------------- ---------------------------------- 5. Most of these practices of these practices are ensured that transplantability Not only in the Linux world, it also includes other UNIX systems. It is not just a professionalistic vague form (Hackerly Politice), and it is easy to understand, it is also valuable insurance for changes in the future Linux itself. Finally, others will try to create your code in a non-Linux system; portability will minimize the annoying, confusing email messages you will get. 5.1 Coding with pure standard C (ANSI C) or portable Script language To transplantability and stability, you should use pure standard C (ANSI C) or portable scripting language, scripting language because there is only one cross-platform implementation It is ensured that it can be portable. Script languages with this qualification include Python, Perl, TCL, and Emacs Lisp. Ordinary old-fashioned shells do not have this eligibility; it has too many different implementations with subtle features, and the Shell environment is customized interferes with users such as shell alias. Java gives a commitment to be transplantable, but the implementation of Linux is still messy and cannot be well integrated with Linux. Although Java became more popular with its maturity, Java is still a choice for paying cost, 5.2 Obtaining a good C Transplanted convention If you use C, don't use any hesitation Standard (ANSI) Features - including function prototype, which will help you find inconsistencies across modules. The old-fashioned K & R compiler has become history. On the other hand, don't assume any GCC-specific features, such as the `-pipe 'option or the nested function, is available. It will wake up in others to non-Linux, non-GCC system, and bite you. 5.3 Using AutoConf / Automake / AutoHeader If you use C, use AutoConf / Automake / AutoHeader to process graft problems, complete system configuration probes, and make your makefiles. Today, people want to enter "configure; make" from the source code, and get a clear creation - and is the case. 5.4 Sanity-check If you use C, use -wall to test compilation and cleare an error before each release. It will find the number of people today. For complete, you have to compile with the -pedantic option.
If you program with Perl, use perl -c (if you can, may be -t) to check your code. Adhere to the P6. Good release creation formula These conventions describe what they look like when someone downloads your release package, how to retrieve and how to unpack. 6.1 Make sure the TAR package always opens a separate new directory to a new developer's error is that the created TAR package will unpack its files and directory into the current directory, this potentially and is already there. The file has a conflict. Never do this! Instead, confirm that your archive file contains a part name of a general directory after the project so that they can be unpacked into a top directory in the current directory. Assuming your publishing directory named `foobar ', and SRC contains a list of files you publish, with a Makefile to complete this task. It requires GNU TAR 1.13vers = 1.0foobar - $ (VERS) .tar.gz: tar --name-prefix = 'foobar - $ (VERS) /' -CZF FOOBAR - $ (VERS) .tar.gz $ (SRC If your TAR is old-fashioned, you do: FooBar - $ (VERS) .tar.gz: @ls $ (src) | SED S: ^: FooBar - $ (VERS) /:> manifest @ ( Cd ..; ln -s foobar foobar - $ (VERS)) (CD ..; tar -czvf foobar / foobar - $ (vers) .tar.gz `cat foobar / manifest`) @ (cd ..; RM Foobar - $ (VERS)) 6.2 Contains a README with a file named readme or read.me, which is the road sign for your source code. According to the past habits, the document is the first file that bravely reads after unpaolding source code. Useful information contained in ReadME includes: a brief description of the project. (If any,) a pointer to the project website Describe the developer's creation environment and potential transplantability. A description of the roadmap of important files and subdirectories. Regarding the guidelines for creating / installed, or pointing to pointers that contain such information (usually install). Regarding the list of maintareaders / awaremers, or points to certain files containing such information (usually Credits) pointers. About engineering recent news, or points to certain files containing such information (usually news) pointers. 6.3 Respecting and obeying the standard file naming practice Even before reading Readme, your brave explorer has viewed the file name in the top-level directory in the release of your unpack. These names itself conveys information. By obeying a standard naming convention, you can provide the explorer with a valuable clue that should read what should be read. Here is some standard top file names and their meaning. Not every release requires all of these files. Readme or Read.Me Roadmark file, first read install configuration, create a list of installation guides Credits Engineering contributors NEWS recent engineering news History project History Copying Project license Terms (GNU Form) license Terms of License Projects Manifest release The list of the common text of the Chinese version FAQ is the common text of the project (FAQ) document Tags Tags to use Emacs or VI, the total habit of the Tag file, all of the file names composed of uppercase letters are human be readable about packages Metainformation, not the ingredients created.
6.4 Provides the RPMS-installed two-in-FAC format is used by the Red Hat Pack Manager, RPM. It appears in most popular Linux releases, and all other Linux issues effectively support it (except Debian and Slackware; and Debian can also be installed from RPM). Therefore, while providing the source code TAR package at your engineering site, it is a good idea to provide an installed RPM package. For you, you are also a good idea to include your source tar package and product produced from your makefile. It is also a good idea in the RPM SPEC file. The SPEC file should use extensions `.spec '; this is how the rpm -t option is how to find it in the TAR package. For special styles, use the shell script that automatically add the correct version number to generate your SPEC file using the shell script that automatically add the correct version number. -------------------------------------------------- ---------------------------- Erl-W and 'Use Strict'. (See the discussion of Perl documentation.) - 7. Good communication practice If you don't know your software, it will not make the world better. Also, make the development project on the Internet will help you find your users and collaborative developers. Here is the standard way to do. 7.1 In C.L.A, the announcement is announced on the new release in Comp.OS.Linux.annsuNware. In addition to itself, the organization is a main supporter similar to Freshmeat, network-based What's-New site. 7.2 Notice in the relevant topic News Group is looking for the USENET topic resistor directly related to your application, and it is necessary to pay above it. Can only be announced in the local code. (For example) if you want to publish the program written in Perl, query the IMAP server program, you should announce on Comp.mail.imap. However, unless the program is also a useful example of the Cutting-Edge Perl Techniques, you may not be published on Comp.lang.Perl. Your statement should contain the URL of the project website. 7.3 Having a website If you intend to create a substantive user and developer community for your project, it should have a website. Standards that should appear on the website are: the charter of the project (why it exists, who is the audience, etc.). Connection to the engineering source code download. How to join an engineering mailing list guide. A list of Frequently Asked Questions. The HTML version of the project documentation to the associated and / or competitive engineering connection. Some sites provide an URL that is anonymous to the main source code tree. 7.4 Provides a list of project collaborators for engineering collaborators, which can communicate and exchange the list of PATCHs is a standard practice. You may also provide a declaration list for people who need to get the progress of the progress in time. 7.5 Released to the main memory in the last few years, Metalab Archive has become the most important LINUX software exchange. Other important locations include: Python Software Activity site (provided for software written using Python). CPAN, complete Perl archive network (provided for software written using Perl).
