|
321
|
1 This file is intended for source package maintainers/distributors.
|
|
|
2
|
|
|
3 This package depends on gnulib, autoconf, automake, and libtool. You will
|
|
|
4 need all these packages installed in order to build from non-release
|
|
|
5 areas in the repository.
|
|
|
6
|
|
|
7 Before a release is made, a branch for that release must be made. Within
|
|
|
8 that branch, all files that will be distributed with the particular release
|
|
|
9 must be generated and added to the repository on that branch. Once the
|
|
|
10 release is deemed stable and ready for release, the release tag should
|
|
|
11 be generated from the head of that particular branch. Thus all release
|
|
|
12 series will have the autotool generated files in the repository as well
|
|
|
13 as any other generated files intended to be distributed.
|
|
|
14
|
|
|
15 Any branch not directly intended to be a release need not include the
|
|
|
16 generated files.
|
|
|
17
|
|
|
18 The trunk development stream must not include the autotool generated files
|
|
|
19 as these are likely to change rapidly and it can cause a great deal of
|
|
|
20 confusion for little gain. Also, the main trunk need not contain such
|
|
|
21 things as generated documentation files for the same reason.
|
|
|
22
|
|
|
23 By including the generated files in the release branches, it is possible
|
|
|
24 to replicate any problems users of the package may have, including if it
|
|
|
25 is due to problems with the autotools themselves.
|
|
|
26
|
|
|
27
|
|
|
28 Naming of branches and tags should conform to the following guidlines.
|
|
|
29
|
|
|
30 1. any branch leading to a release series must be named as the base revision
|
|
|
31 of the series. Thus, for a 1.0 release, the branch is called 1.0 and will
|
|
|
32 contain the results for a 1.0 release, a 1.0.1 release, and so on. If a
|
|
|
33 sub-release will occur, say under 1.0.1, then a branch named "1.0.1" would
|
|
|
34 be created and then releases such as 1.0.1.1 would be created. This should
|
|
|
35 be avoided if at all possible.
|
|
|
36
|
|
|
37 2. any tag for a specific release version will be named as the release. So
|
|
|
38 for a 1.0 release, the name would be "1.0". For version 1.0.1.1, the name
|
|
|
39 would be "1.0.1.1".
|
|
|
40
|
|
|
41 3. branches not associated with a release stream - say for feature development
|
|
|
42 or what have you should be named sensibly and should be removed when no longer
|
|
|
43 needed. They must not appear to be version numbers.
|
|
|
44
|
|
|
45 4. tags not specifying a release must not look like version numbers
|
