48 |
* Changes other than bug fixes must be mentioned in NEWS |
* Changes other than bug fixes must be mentioned in NEWS |
49 |
|
|
50 |
|
|
51 |
2. Test Suite |
3. Test Suite |
52 |
============= |
============= |
53 |
|
|
54 |
* Use "make check" liberally, on as many platforms as you can. Use as |
* Use "make check" liberally, on as many platforms as you can. Use as |
55 |
many compilers and linkers you can. |
many compilers and linkers you can. |
56 |
|
|
57 |
|
|
58 |
3. Naming |
4. Naming |
59 |
========= |
========= |
60 |
|
|
61 |
* We've adopted the convention that exported Autoconf macros should be |
* We've adopted the convention that exported Autoconf macros should be |
71 |
with the `_lt_' macro namespace). |
with the `_lt_' macro namespace). |
72 |
|
|
73 |
|
|
74 |
4. Editing `.am' Files |
5. Editing 'ChangeLog' |
75 |
|
====================== |
76 |
|
|
77 |
|
* When in doubt, check that emacs can syntax-color properly in |
78 |
|
change-log-mode. And preferably use emacs 'C-x 4 a' |
79 |
|
(add-change-log-entry-other-window) to open ChangeLog with an |
80 |
|
appropriate new template. |
81 |
|
|
82 |
|
* If this change is by a different author, or on a different date to the |
83 |
|
last entry start a new entry at the top of the file with the format |
84 |
|
(note two spaces between each field): |
85 |
|
|
86 |
|
yyyy-mm-dd Name of Author <email@address> |
87 |
|
|
88 |
|
* 'Name of Author' is the name of the person who made the change being |
89 |
|
documented, or if that person didn't supply a ChangeLog, the author |
90 |
|
of the ChangeLog entry. If more than one person collaborated on the |
91 |
|
change, additional authors can be listed on subsequent lines, thus: |
92 |
|
|
93 |
|
yyyy-mm-dd Name of Main Author <email@address>, |
94 |
|
Name of Contributor <another@email.address> |
95 |
|
|
96 |
|
* Preferably the next part should be a description of the overall |
97 |
|
purpose of the change, separated from the header by a blank line, |
98 |
|
indented by 1 tab, and filled at column 72. The last character of the |
99 |
|
description should be a colon, :. |
100 |
|
|
101 |
|
* If the author of the change is different from the author of the |
102 |
|
ChangeLog, then the change outhor should be credited, separated from |
103 |
|
the previous field by a blank line and indented by 1 tab (note, only |
104 |
|
1 space between fields here): |
105 |
|
|
106 |
|
From Author of Actual Change <email@address>: |
107 |
|
|
108 |
|
* Changes to each file come next. Each new file starts on a new line, |
109 |
|
indented by 1 tab and starting with an asterisk and a space. Multiple |
110 |
|
files can be listed here relative to $top_srcdir, and comma separated. |
111 |
|
Names of functions (or sections as appropriate) to which the change |
112 |
|
applies should be named inside parentheses and comma separated. If |
113 |
|
this goes beyond column 72, then parens should be closed and re-opened |
114 |
|
on the next line: |
115 |
|
|
116 |
|
* file, another/file, test/testcases/foo.test (func_foo) |
117 |
|
(func_bar, func_baz): Description of changes. |
118 |
|
|
119 |
|
* If the change does not apply to particular functions (or sections), |
120 |
|
the section list can be omitted: |
121 |
|
|
122 |
|
* file, another/file, test/testcases/foo.test: General changes. |
123 |
|
|
124 |
|
* If the changes are particular to certain architectures, they should be |
125 |
|
listed after the functions in square brackets: |
126 |
|
|
127 |
|
* file, another/file (func_foo) [linux, solaris]: Description of |
128 |
|
changes. |
129 |
|
|
130 |
|
* Subsequent changes in other files that are related to the same overall |
131 |
|
enhancement or bugfix should be listed concurrently, without blank |
132 |
|
lines. Always start a fresh line for a new file: |
133 |
|
|
134 |
|
* file, another/file (func_foo) [linux, solaris]: Description of |
135 |
|
changes. |
136 |
|
* doc/foo.texi (Invoking Foo): Document. |
137 |
|
* NEWS: Updated. |
138 |
|
|
139 |
|
* If the change is in response to a problem reported by someone other |
140 |
|
than the author, then credit them at the end of the description with: |
141 |
|
|
142 |
|
Reported by Reporter Name <email@address>. |
143 |
|
|
144 |
|
* See the GNU Coding Standards document for more details on ChangeLog |
145 |
|
formatting. |
146 |
|
|
147 |
|
|
148 |
|
2005-01-08 Gary V. Vaughan <gary@gnu.org>, |
149 |
|
Peter O'Gorman <peter@pogma.com> |
150 |
|
|
151 |
|
This is the overall description of the purpose of this change |
152 |
|
and any useful background for a model ChangeLog entry: |
153 |
|
|
154 |
|
From Ralf Wildenhues <Ralf.Wildenhues@gmx.de>: |
155 |
|
* HACKING: Updated copyright. This isn't attached to a |
156 |
|
particular section of the file, so it comes first. |
157 |
|
(Editing 'ChangeLog'): New section. This applies to the same |
158 |
|
file, but since it applies to a particular section it starts on |
159 |
|
a new line. |
160 |
|
(Introduction, Maintenance Notes, Test Suite, Naming) |
161 |
|
(Editing '.am' Files): If I had changed all these sections in |
162 |
|
the same way, I can list them like this, being careful to close |
163 |
|
and reopen the parentheses when starting a new line. The colon |
164 |
|
only comes after the last section before this description. |
165 |
|
* NEWS: Updated. |
166 |
|
Reported by Bob Friesenhahn <bfriesen@simple.dallas.tx.us>. |
167 |
|
|
168 |
|
|
169 |
|
6. Editing `.am' Files |
170 |
====================== |
====================== |
171 |
|
|
172 |
* Always use $(...) and not ${...} |
* Always use $(...) and not ${...} |
184 |
of the loop itself should print each "important" command it runs. |
of the loop itself should print each "important" command it runs. |
185 |
|
|
186 |
|
|
187 |
5. Editing `.m4sh' Files |
7. Editing `.m4sh' Files |
188 |
======================== |
======================== |
189 |
|
|
190 |
* Use shell functions, but be careful not to assume local scope for |
* Use shell functions, but be careful not to assume local scope for |
205 |
functions should begin indented by 4 spaces. |
functions should begin indented by 4 spaces. |
206 |
|
|
207 |
|
|
208 |
6. Abstraction layers in libltdl |
8. Abstraction layers in libltdl |
209 |
================================ |
================================ |
210 |
|
|
211 |
* The libltdl API uses a layered approach to differentiate internal and |
* The libltdl API uses a layered approach to differentiate internal and |
289 |
lt__private.h |
lt__private.h |
290 |
|
|
291 |
|
|
292 |
7. Release Procedure |
9. Release Procedure |
293 |
==================== |
==================== |
294 |
|
|
295 |
* If you are a libtool maintainer, but have not yet registered your |
* If you are a libtool maintainer, but have not yet registered your |
376 |
|
|
377 |
|
|
378 |
|
|
379 |
7. Alpha release note template |
10. Alpha release note template |
380 |
============================== |
=============================== |
381 |
|
|
382 |
To: libtool@gnu.org, autotools-announce@gnu.org |
To: libtool@gnu.org, autotools-announce@gnu.org |
383 |
Subject: GNU Libtool @VERSION@ released (alpha release). |
Subject: GNU Libtool @VERSION@ released (alpha release). |
449 |
|
|
450 |
|
|
451 |
|
|
452 |
8. Full release note template |
11. Full release note template |
453 |
============================= |
============================== |
454 |
|
|
455 |
To: info-gnu@gnu.org |
To: info-gnu@gnu.org |
456 |
Cc: libtool@gnu.org, autotools-announce@gnu.org |
Cc: libtool@gnu.org, autotools-announce@gnu.org |
531 |
|
|
532 |
|
|
533 |
-- |
-- |
534 |
Copyright (C) 2004 Free Software Foundation, Inc. |
Copyright (C) 2004, 2005 Free Software Foundation, Inc. |
535 |
|
|
536 |
The canonical source of this file is maintained with the |
The canonical source of this file is maintained with the |
537 |
GNU Libtool package. Report bugs to bug-libtool@gnu.org. |
GNU Libtool package. Report bugs to bug-libtool@gnu.org. |