Mercurial > hg-old > index.cgi
annotate README.MAINT @ 197:12fb4e8d5236
Add .end as synonym for end
author | lost |
---|---|
date | Sun, 22 Mar 2009 18:01:30 +0000 |
parents | 69ead2e61763 |
children |
rev | line source |
---|---|
2 | 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 | |
107
69ead2e61763
Added start of a manual and updated maintainer docs to mention generated documentation
lost
parents:
2
diff
changeset
|
8 series will have the autotool generated files in the repository as well |
69ead2e61763
Added start of a manual and updated maintainer docs to mention generated documentation
lost
parents:
2
diff
changeset
|
9 as any other generated files intended to be distributed. |
2 | 10 |
11 Any branch not directly intended to be a release need not include the | |
107
69ead2e61763
Added start of a manual and updated maintainer docs to mention generated documentation
lost
parents:
2
diff
changeset
|
12 generated files. |
2 | 13 |
14 The trunk development stream must not include the autotool generated files | |
15 as these are likely to change rapidly and it can cause a great deal of | |
107
69ead2e61763
Added start of a manual and updated maintainer docs to mention generated documentation
lost
parents:
2
diff
changeset
|
16 confusion for little gain. Also, the main trunk need not contain such |
69ead2e61763
Added start of a manual and updated maintainer docs to mention generated documentation
lost
parents:
2
diff
changeset
|
17 things as generated documentation files for the same reason. |
2 | 18 |
19 By including the generated files in the release branches, it is possible | |
20 to replicate any problems users of the package may have, including if it | |
21 is due to problems with the autotools themselves. | |
22 | |
23 | |
24 Naming of branches and tags should conform to the following guidlines. | |
25 | |
26 1. any branch leading to a release series must be named as the base revision | |
27 of the series. Thus, for a 1.0 release, the branch is called 1.0 and will | |
28 contain the results for a 1.0 release, a 1.0.1 release, and so on. If a | |
29 sub-release will occur, say under 1.0.1, then a branch named "1.0.1" would | |
30 be created and then releases such as 1.0.1.1 would be created. This should | |
31 be avoided if at all possible. | |
32 | |
33 2. any tag for a specific release version will be named as the release. So | |
34 for a 1.0 release, the name would be "1.0". For version 1.0.1.1, the name | |
35 would be "1.0.1.1". | |
36 | |
37 3. branches not associated with a release stream - say for feature development | |
38 or what have you should be named sensibly and should be removed when no longer | |
39 needed. They must not appear to be version numbers. | |
40 | |
41 4. tags not specifying a release must not look like version numbers |