Mercurial > hg-old > index.cgi
view README.MAINT @ 245:eb499c146c0d 2.x
Fixed selection of objects for inclusion from within libraries to actually resolve references correctly
author | lost |
---|---|
date | Thu, 19 Nov 2009 00:51:31 +0000 |
parents | 69ead2e61763 |
children |
line wrap: on
line source
This file is intended for source package maintainers/distributors. 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