2620 |
will be useful on GNU and GNU/Linux, rather than on supporting other |
will be useful on GNU and GNU/Linux, rather than on supporting other |
2621 |
incompatible systems. |
incompatible systems. |
2622 |
|
|
2623 |
|
If you do support Windows, please do not abbreviate it as ``win''. In |
2624 |
|
hacker terminology, calling something a ``win'' is a form of praise. |
2625 |
|
You're free to praise Microsoft Windows on your own if you want, but |
2626 |
|
please don't do this in GNU packages. Instead of abbreviating |
2627 |
|
``Windows'' to ``un'', you can write it in full or abbreviate it to |
2628 |
|
``woe'' or ``w''. In GNU Emacs, for instance, we use @samp{w32} in |
2629 |
|
file names of Windows-specific files, but the macro for Windows |
2630 |
|
conditionals is called @code{WINDOWSNT}. |
2631 |
|
|
2632 |
It is a good idea to define the ``feature test macro'' |
It is a good idea to define the ``feature test macro'' |
2633 |
@code{_GNU_SOURCE} when compiling your C files. When you compile on GNU |
@code{_GNU_SOURCE} when compiling your C files. When you compile on GNU |
2634 |
or GNU/Linux, this will enable the declarations of GNU library extension |
or GNU/Linux, this will enable the declarations of GNU library extension |
3673 |
@section Making Releases |
@section Making Releases |
3674 |
@cindex packaging |
@cindex packaging |
3675 |
|
|
3676 |
|
You should identify each release with a pair of version numbers, a |
3677 |
|
major version and a minor. We have no objection to using more than |
3678 |
|
two numbers, but it is very unlikely that you really need them. |
3679 |
|
|
3680 |
Package the distribution of @code{Foo version 69.96} up in a gzipped tar |
Package the distribution of @code{Foo version 69.96} up in a gzipped tar |
3681 |
file with the name @file{foo-69.96.tar.gz}. It should unpack into a |
file with the name @file{foo-69.96.tar.gz}. It should unpack into a |
3682 |
subdirectory named @file{foo-69.96}. |
subdirectory named @file{foo-69.96}. |