view README.MAINT @ 363:d96c30e60ddf

Added pass2 and various supporting logic including symbol lookups
author lost@starbug
date Tue, 06 Apr 2010 21:03:19 -0600
parents 219672663ad8
children
line wrap: on
line source

This file is intended for source package maintainers/distributors.

This package depends on gnulib, autoconf, automake, and libtool. You will
need all these packages installed in order to build from non-release
areas in the repository.

Before a release is made, a branch for that release must be made. Within
that branch, all files that will be distributed with the particular release
must be generated and added to the repository on that branch. Once the
release is deemed stable and ready for release, the release tag should
be generated from the head of that particular branch. Thus all release
series will have the autotool generated files in the repository as well
as any other generated files intended to be distributed.

Any branch not directly intended to be a release need not include the
generated files.

The trunk development stream must not include the autotool generated files
as these are likely to change rapidly and it can cause a great deal of
confusion for little gain. Also, the main trunk need not contain such
things as generated documentation files for the same reason.

By including the generated files in the release branches, it is possible
to replicate any problems users of the package may have, including if it
is due to problems with the autotools themselves.


Naming of branches and tags should conform to the following guidlines.

1. any branch leading to a release series must be named as the base revision
of the series. Thus, for a 1.0 release, the branch is called 1.0 and will
contain the results for a 1.0 release, a 1.0.1 release, and so on. If a
sub-release will occur, say under 1.0.1, then a branch named "1.0.1" would
be created and then releases such as 1.0.1.1 would be created. This should
be avoided if at all possible.

2. any tag for a specific release version will be named as the release. So
for a 1.0 release, the name would be "1.0". For version 1.0.1.1, the name
would be "1.0.1.1".

3. branches not associated with a release stream - say for feature development
or what have you should be named sensibly and should be removed when no longer
needed. They must not appear to be version numbers.

4. tags not specifying a release must not look like version numbers