Mercurial > hg-old > index.cgi
diff old-trunk/README.MAINT @ 339:eb230fa7d28e
Prepare for migration to hg
author | lost |
---|---|
date | Fri, 19 Mar 2010 02:54:14 +0000 |
parents | |
children |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/old-trunk/README.MAINT Fri Mar 19 02:54:14 2010 +0000 @@ -0,0 +1,41 @@ +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