Mercurial > hg-old > index.cgi
comparison README.MAINT @ 2:a8a83ccffafd
Converted to automake/autoconf
| author | lost |
|---|---|
| date | Fri, 03 Oct 2008 06:13:26 +0000 |
| parents | |
| children | 69ead2e61763 |
comparison
equal
deleted
inserted
replaced
| 1:b6f398718389 | 2:a8a83ccffafd |
|---|---|
| 1 This file is intended for source package maintainers/distributors. | |
| 2 | |
| 3 Before a release is made, a branch for that release must be made. Within | |
| 4 that branch, all files that will be distributed with the particular release | |
| 5 must be generated and added to the repository on that branch. Once the | |
| 6 release is deemed stable and ready for release, the release tag should | |
| 7 be generated from the head of that particular branch. Thus all release | |
| 8 series will have the autotool generated files in the repository. | |
| 9 | |
| 10 Any branch not directly intended to be a release need not include the | |
| 11 autotool generated files. | |
| 12 | |
| 13 The trunk development stream must not include the autotool generated files | |
| 14 as these are likely to change rapidly and it can cause a great deal of | |
| 15 confusion for little gain. | |
| 16 | |
| 17 By including the generated files in the release branches, it is possible | |
| 18 to replicate any problems users of the package may have, including if it | |
| 19 is due to problems with the autotools themselves. | |
| 20 | |
| 21 | |
| 22 Naming of branches and tags should conform to the following guidlines. | |
| 23 | |
| 24 1. any branch leading to a release series must be named as the base revision | |
| 25 of the series. Thus, for a 1.0 release, the branch is called 1.0 and will | |
| 26 contain the results for a 1.0 release, a 1.0.1 release, and so on. If a | |
| 27 sub-release will occur, say under 1.0.1, then a branch named "1.0.1" would | |
| 28 be created and then releases such as 1.0.1.1 would be created. This should | |
| 29 be avoided if at all possible. | |
| 30 | |
| 31 2. any tag for a specific release version will be named as the release. So | |
| 32 for a 1.0 release, the name would be "1.0". For version 1.0.1.1, the name | |
| 33 would be "1.0.1.1". | |
| 34 | |
| 35 3. branches not associated with a release stream - say for feature development | |
| 36 or what have you should be named sensibly and should be removed when no longer | |
| 37 needed. They must not appear to be version numbers. | |
| 38 | |
| 39 4. tags not specifying a release must not look like version numbers |