LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

updated

This commit is contained in:
gferg 2000-06-02 13:20:56 +00:00
parent 3d0bcd86ac
commit b009e764d4
2 changed files with 34 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
LDP/howto/linuxdoc/HOWTO-INDEX.sgml
View File

@ -869,7 +869,7 @@ extension, the associated tools, and their use. This HOWTO addresses
an earlier implementation.
<item><htmlurl url="Software-Release-Practice-HOWTO.html" name="Software-Release-Practice-HOWTO">,
<BF/Software Release Practice HOWTO/ <p><em/Updated: January 2000/.
<BF/Software Release Practice HOWTO/ <p><em/Updated: June 2000/.
Describes good release practices for Linux open-source projects.
<item><htmlurl url="Sound-HOWTO.html" name="Sound-HOWTO">,
@ -1570,6 +1570,10 @@ describes how to disable audible bells on demand.
<BF>The VPN HOWTO</BF> <P><em/Updated: August 1997/.
How to setup a Virtual Private Network.
<item><htmlurl url="mini/Wacom-USB-mini-HOWTO.html" name="Wacom-USB-mini-HOWTO">,
<BF>Wacom Graphire USB Mini-HOWTO</BF> <P><em/Updated: June 2000/.
How to setup a Wacom Graphire USB tablet for use with Linux.
<item><htmlurl url="mini/WordPerfect.html" name="WordPerfect">,
<BF>WordPerfect Mini-howto</BF> <P><em/Updated: August 1997/.
Discusses running WordPerfect on Linux, including a brief discussion

31
LDP/howto/linuxdoc/Software-Release-Practice-HOWTO.sgml
View File

@ -9,7 +9,7 @@
<title>Software Release Practice HOWTO
<author>Eric S. Raymond &lt;esr@thyrsus.com&gt;
<date>2.2, 11 January 2000
<date>2.3, 1 June 2000
<abstract>
This HOWTO describes good release practices for Linux open-source projects.
@ -451,6 +451,32 @@ is valuable. Among other things, it may help establish prior art if
you are ever hit with a patent-infringement lawsuit (this hasn't
happened to anyone yet, but best to be prepared).
<sect1>Design for Upgradability
<p>
Your software will change over time as you put out new releases. Some
of these changes will not be backward-compatible. Accordingly, you
should give serious thought to designing your installation layouts so
that multiple installed versions of your code can coexist on the same
system. This is especially important for libraries -- you can't
count on all your client programs to upgrade in lockstep with your
API changes.
The Emacs, Python, and Qt projects have a good convention for handling
this; version-numbered directories. Here's how an installed Qt
library hierarchy looks (&dollar;{ver} is the version number):
<verb>
/usr/lib/qt
/usr/lib/qt-${ver}
/usr/lib/qt-${ver}/bin # Where you find moc
/usr/lib/qt-${ver}/lib # Where you find .so
/usr/lib/qt-${ver}/include # Where you find header files
</verb>
With this organization, you can have multiple versions coexisting.
Client programs have to specify the library version they want, but
that's a small price to pay for not having the interfaces break on them.
<sect1>Provide RPMs
<p>
The de-facto standard format for installable binary packages is that used
@ -478,7 +504,7 @@ exists. Also, developing a visible presence for the project on the
Internet will assist you in recruiting users and co-developers. Here
are the standard ways to do that.
<sect1>Announce to c.o.l.a
<sect1>Announce to c.o.l.a and Freshmeat
<p>
Announce new releases to <url url="news:comp.os.linux.announce"
name="comp.os.linux.announce">. Besides being widely read itself,
@ -569,3 +595,4 @@ fill-column:75
compile-command:"make Software-Release-Practice-HOWTO.html"
End:
-- >