39 |
doc/ |
doc/ |
40 |
+ fdl.texi |
+ fdl.texi |
41 |
libltdl/ |
libltdl/ |
42 |
+ COPYING.LIB |
+ COPYING.LESSER |
43 |
|
+ config.guess |
44 |
|
+ config.sub |
45 |
|
+ install-sh |
46 |
|
+ missing |
47 |
The ones that are important for a release can be udated with, |
The ones that are important for a release can be udated with, |
48 |
`make -fMakefile.maint fetch' (or `make -f../Makefile.maint fetch' |
`make -fMakefile.maint fetch' (or `make -f../Makefile.maint fetch' |
49 |
if you are running from a VPATH build directory, where `../' is the |
if you are running from a VPATH build directory, where `../' is the |
52 |
* Changes other than bug fixes must be mentioned in NEWS |
* Changes other than bug fixes must be mentioned in NEWS |
53 |
|
|
54 |
|
|
55 |
3. Test Suite |
2. Test Suite |
56 |
============= |
============= |
57 |
|
|
58 |
* 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 |
59 |
many compilers and linkers you can. |
many compilers and linkers you can. |
60 |
|
|
61 |
|
|
62 |
4. Naming |
3. Naming |
63 |
========= |
========= |
64 |
|
|
65 |
* We've adopted the convention that exported Autoconf macros should be |
* We've adopted the convention that exported Autoconf macros should be |
75 |
with the `_lt_' macro namespace). |
with the `_lt_' macro namespace). |
76 |
|
|
77 |
|
|
78 |
5. Editing 'ChangeLog' |
4. Editing `.am' Files |
|
====================== |
|
|
|
|
|
* When in doubt, check that emacs can syntax-color properly in |
|
|
change-log-mode. And preferably use emacs 'C-x 4 a' |
|
|
(add-change-log-entry-other-window) to open ChangeLog with an |
|
|
appropriate new template. |
|
|
|
|
|
* If this change is by a different author, or on a different date to the |
|
|
last entry start a new entry at the top of the file with the format |
|
|
(note two spaces between each field): |
|
|
|
|
|
yyyy-mm-dd Name of Author <email@address> |
|
|
|
|
|
* If more than one person collaborated on the change, additional |
|
|
authors can be listed on subsequent lines, thus: |
|
|
|
|
|
yyyy-mm-dd Name of Main Author <email@address>, |
|
|
Name of Contributor <another@email.address> |
|
|
|
|
|
* Where a change author did not supply a copyright assignment, but the |
|
|
changes they submitted were sufficiently trivial to commit in any case |
|
|
(see the GCS for guidelines on this), then flag this against their |
|
|
name in the header, thus: |
|
|
|
|
|
yyyy-mm-dd Name of Author <email@address> (tiny change) |
|
|
|
|
|
* In ChangeLog.2004 and earlier, 'Name of Author' was sometimes the name |
|
|
of the author of the ChangeLog when the person who made the change |
|
|
being documented didn't supply one. In that case separated from |
|
|
the previous field by a blank line and indented by 1 tab (note, only |
|
|
1 space between fields here) you will see: |
|
|
|
|
|
From Author of Actual Change <email@address>: |
|
|
|
|
|
As of now, don't do that anymore, since the GNU Coding Standards say |
|
|
that the author of the change must be credited in the main entry |
|
|
header for legal purposes. |
|
|
|
|
|
* Preferably the next part should be a description of the overall |
|
|
purpose of the change, separated from the header by a blank line, |
|
|
indented by 1 tab, and filled at column 72. The last character of the |
|
|
description should be a colon, :. |
|
|
|
|
|
* Changes to each file come next. Each new file starts on a new line, |
|
|
indented by 1 tab and starting with an asterisk and a space. Multiple |
|
|
files can be listed here relative to $top_srcdir, and comma separated. |
|
|
Names of functions (or sections as appropriate) to which the change |
|
|
applies should be named inside parentheses and comma separated. If |
|
|
this goes beyond column 72, then parens should be closed and re-opened |
|
|
on the next line: |
|
|
|
|
|
* file, another/file, test/testcases/foo.test (func_foo) |
|
|
(func_bar, func_baz): Description of changes. |
|
|
|
|
|
* If the change does not apply to particular functions (or sections), |
|
|
the section list can be omitted: |
|
|
|
|
|
* file, another/file, test/testcases/foo.test: General changes. |
|
|
|
|
|
* If the changes are particular to certain architectures, they should be |
|
|
listed after the functions in square brackets: |
|
|
|
|
|
* file, another/file (func_foo) [linux, solaris]: Description of |
|
|
changes. |
|
|
|
|
|
* Subsequent changes in other files that are related to the same overall |
|
|
enhancement or bugfix should be listed concurrently, without blank |
|
|
lines. Always start a fresh line for a new file: |
|
|
|
|
|
* file, another/file (func_foo) [linux, solaris]: Description of |
|
|
changes. |
|
|
* doc/foo.texi (Invoking Foo): Document. |
|
|
* NEWS: Updated. |
|
|
|
|
|
* If the change is in response to a problem reported by someone other |
|
|
than the author, then credit them at the end of the description with: |
|
|
|
|
|
Reported by Reporter Name <email@address>. |
|
|
|
|
|
* See the GNU Coding Standards document for more details on ChangeLog |
|
|
formatting. |
|
|
|
|
|
|
|
|
2005-01-08 Ralf Wildenhues <Ralf.Wildenhues@gmx.de> (tiny change), |
|
|
Peter O'Gorman <peter@pogma.com> |
|
|
|
|
|
This is the overall description of the purpose of this change |
|
|
and any useful background for a model ChangeLog entry: |
|
|
|
|
|
* HACKING: Updated copyright. This isn't attached to a |
|
|
particular section of the file, so it comes first. |
|
|
(Editing 'ChangeLog'): New section. This applies to the same |
|
|
file, but since it applies to a particular section it starts on |
|
|
a new line. |
|
|
(Introduction, Maintenance Notes, Test Suite, Naming) |
|
|
(Editing '.am' Files): If I had changed all these sections in |
|
|
the same way, I can list them like this, being careful to close |
|
|
and reopen the parentheses when starting a new line. The colon |
|
|
only comes after the last section before this description. |
|
|
* NEWS: Updated. |
|
|
Reported by Bob Friesenhahn <bfriesen@simple.dallas.tx.us>. |
|
|
|
|
|
|
|
|
6. Editing `.am' Files |
|
79 |
====================== |
====================== |
80 |
|
|
81 |
* Always use $(...) and not ${...} |
* Always use $(...) and not ${...} |
86 |
|
|
87 |
* Never use basename or dirname. Instead use sed. |
* Never use basename or dirname. Instead use sed. |
88 |
|
|
89 |
* Do not use `cd' within back-quotes, use `$(lt__cd)' instead. |
* Do not use `cd' within back-quotes, use `$(am__cd)' instead. |
90 |
Otherwise the directory name may be printed, depending on CDPATH. |
Otherwise the directory name may be printed, depending on CDPATH. |
91 |
|
|
92 |
* In general, if a loop is required, it should be silent. Then the body |
* In general, if a loop is required, it should be silent. Then the body |
93 |
of the loop itself should print each "important" command it runs. |
of the loop itself should print each "important" command it runs. |
94 |
|
|
95 |
|
|
96 |
7. Editing `.m4sh' Files |
5. Editing `.m4sh' Files |
97 |
======================== |
======================== |
98 |
|
|
99 |
* Use shell functions, but be careful not to assume local scope for |
* Use shell functions, but be careful not to assume local scope for |
100 |
variable names. Don't use `return', instead echo the result of a |
variable names. Don't use `return', instead echo the result of a |
101 |
function and call it from within backquotes. |
function and call it from within backquotes. |
102 |
|
|
103 |
* Function names should be prefixed `func_', the function header should |
* Function names should be prefixed `func_'. |
|
look like this: |
|
|
|
|
|
# func_foo [ OPTIONS ] |
|
|
# Description of what func_foo does and returns. |
|
|
func_foo () |
|
|
{ |
|
|
$opt_debug |
|
|
# contents of func_foo ... |
|
|
} |
|
|
|
|
|
The `$opt_debug' is used to enable shell tracing (Korn shells reset |
|
|
this on function entry). |
|
104 |
|
|
105 |
* For functions that are called frequently, if you need to return a |
* For functions that are called frequently, if you need to return a |
106 |
value, don't cause unneccessary forking of the shell using echo as |
value, don't cause unneccessary forking of the shell using echo as |
114 |
functions should begin indented by 4 spaces. |
functions should begin indented by 4 spaces. |
115 |
|
|
116 |
|
|
117 |
8. Editing `.m4' Files |
6. Abstraction layers in libltdl |
|
====================== |
|
|
|
|
|
* Be careful with both `echo' and `$ECHO'. As the latter may be one of |
|
|
echo |
|
|
print -r |
|
|
printf %s\n |
|
|
$CONFIG_SHELL $0 --fallback-echo |
|
|
it may not have more than one argument, its value may not be eval'ed |
|
|
and the argument may not start with a `-'. As a rule of thumb, use |
|
|
echo .. for literal (constant) strings without leading |
|
|
hyphen and no backslashes within, |
|
|
$ECHO ".." for strings without leading hyphen, |
|
|
$ECHO "X.." | $Xsed otherwise. |
|
|
|
|
|
|
|
|
9. Abstraction layers in libltdl |
|
118 |
================================ |
================================ |
119 |
|
|
120 |
* The libltdl API uses a layered approach to differentiate internal and |
* The libltdl API uses a layered approach to differentiate internal and |
198 |
lt__private.h |
lt__private.h |
199 |
|
|
200 |
|
|
201 |
10. Release Procedure |
7. Release Procedure |
202 |
==================== |
==================== |
203 |
|
|
204 |
* If you are a libtool maintainer, but have not yet registered your |
* If you are a libtool maintainer, but have not yet registered your |
217 |
keys will be registered on ftp-upload.gnu.org and only then will you be |
keys will be registered on ftp-upload.gnu.org and only then will you be |
218 |
authorized to upload files to the FSF ftp machines. |
authorized to upload files to the FSF ftp machines. |
219 |
|
|
|
* If you do not have access to the mailing list administrative interface, |
|
|
approach the list owners for the password. Be sure to check the lists |
|
|
(esp. bug-libtool) for outstanding bug reports also in the list of |
|
|
pending moderation requests. |
|
|
|
|
220 |
* Make sure you have wget installed. |
* Make sure you have wget installed. |
221 |
|
|
222 |
* Make sure you have a copy of xdelta installed, and a copy of the previous |
* Make sure you have a copy of xdelta installed, and a copy of the previous |
223 |
release tarball in the build directory. |
release tarball in the build directory. |
224 |
|
|
|
* Make sure your locale is sane, e.g. by exporting LC_ALL=C. |
|
|
|
|
|
* Double check that serial number updates in public m4 files weren't forgotten |
|
|
since last release (they should be updated in CVS along with commits that |
|
|
require it so that users can work with CVS snapshots). |
|
|
|
|
|
* Double check that libltdl version number updates weren't forgotten since last |
|
|
release (they should be updated in CVS along with commits that require it so |
|
|
that users can work with CVS snapshots). |
|
|
|
|
225 |
* Update the version number in configure.ac. |
* Update the version number in configure.ac. |
226 |
See http://www.gnu.org/software/libtool/contribute.html for details of |
See http://www.gnu.org/software/libtool/contribute.html for details of |
227 |
the numbering scheme. |
the numbering scheme. |
242 |
fetch new versions of the files that are maintained outside of |
fetch new versions of the files that are maintained outside of |
243 |
libtool. |
libtool. |
244 |
|
|
245 |
* Run `make distcheck' and `make distcheck |
* Run `make distcheck'. If there are any problems, fix them and start |
246 |
DISTCHECK_CONFIGURE_FLAGS=--disable-ltdl-install'. If there are any |
again. |
|
problems, fix them and start again. |
|
247 |
|
|
248 |
* Run ./commit from the source tree. |
* Run ./commit from the source tree. |
249 |
|
|
254 |
with release-$(VERSION) and generate the gpg signature files. |
with release-$(VERSION) and generate the gpg signature files. |
255 |
|
|
256 |
* Run 'make -f[../]Makefile.maint deltas' (pass |
* Run 'make -f[../]Makefile.maint deltas' (pass |
257 |
LASTRELEASE=maj.min[.mic[alpha]] if needed) to create both diff and |
LASTRELEASE=min.maj[.mic[alpha]] if needed) to create both diff and |
258 |
xdelta files between the previous release tarball and the new with |
xdelta files between the previous release tarball and the new with |
259 |
detached gpg signature files and clear signed directive files. |
detached gpg signature files and clear signed directive files. |
260 |
|
|
285 |
|
|
286 |
|
|
287 |
|
|
288 |
11. Alpha release note template |
7. Alpha release note template |
289 |
=============================== |
============================== |
290 |
|
|
291 |
To: libtool@gnu.org, autotools-announce@gnu.org |
To: libtool@gnu.org, autotools-announce@gnu.org |
292 |
Subject: GNU Libtool @VERSION@ released (alpha release). |
Subject: GNU Libtool @VERSION@ released (alpha release). |
319 |
You should download the signature named after any tarball you download, |
You should download the signature named after any tarball you download, |
320 |
and then verify its integrity with, for example: |
and then verify its integrity with, for example: |
321 |
|
|
322 |
gpg --verify libtool-@VERSION.tar.gz.sig |
gpg --verify libtool-@VERSION.tar.gz. |
323 |
|
|
324 |
Here are the MD5 and SHA1 checksums: |
Here are the MD5 and SHA1 checksums: |
325 |
|
|
358 |
|
|
359 |
|
|
360 |
|
|
361 |
12. Full release note template |
8. Full release note template |
362 |
============================== |
============================= |
363 |
|
|
364 |
To: info-gnu@gnu.org |
To: info-gnu@gnu.org |
365 |
Cc: libtool@gnu.org, autotools-announce@gnu.org |
Cc: libtool@gnu.org, autotools-announce@gnu.org |
370 |
|
|
371 |
GNU Libtool hides the complexity of using shared libraries behind a |
GNU Libtool hides the complexity of using shared libraries behind a |
372 |
consistent, portable interface. GNU Libtool ships with GNU libltdl, |
consistent, portable interface. GNU Libtool ships with GNU libltdl, |
373 |
which hides the complexity of loading dynamic runtime libraries |
which hides the comlexity of loading dynamic runtime libraries |
374 |
(modules) behind a consistent, portable interface. |
(modules) behind a consistent, portable interface. |
375 |
|
|
376 |
This release has @SUMMARY_OF_IMPROVEMENTS_SINCE_LAST_RELEASE_ON_THIS_BRANCH@. |
This release has @SUMMARY_OF_IMPROVEMENTS_SINCE_LAST_RELEASE_ON_THIS_BRANCH@. |
406 |
You should download the signature named after any tarball you download, |
You should download the signature named after any tarball you download, |
407 |
and then verify its integrity with, for example: |
and then verify its integrity with, for example: |
408 |
|
|
409 |
gpg --verify libtool-@VERSION.tar.gz.sig |
gpg --verify libtool-@VERSION.tar.gz. |
410 |
|
|
411 |
Here are the MD5 and SHA1 checksums: |
Here are the MD5 and SHA1 checksums: |
412 |
|
|
440 |
|
|
441 |
|
|
442 |
-- |
-- |
443 |
Copyright (C) 2004, 2005 Free Software Foundation, Inc. |
Copyright (C) 2004 Free Software Foundation, Inc. |
444 |
|
|
445 |
The canonical source of this file is maintained with the |
The canonical source of this file is maintained with the |
446 |
GNU Libtool package. Report bugs to bug-libtool@gnu.org. |
GNU Libtool package. Report bugs to bug-libtool@gnu.org. |
462 |
|
|
463 |
You should have received a copy of the GNU General Public License |
You should have received a copy of the GNU General Public License |
464 |
along with GNU Libtool; if not, write to the Free Software |
along with GNU Libtool; if not, write to the Free Software |
465 |
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA |
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA |
466 |
02110-1301 USA |
02111-1307 USA |
467 |
|
|
468 |
|
|
469 |
Local Variables: |
Local Variables: |