Mercurial > hg-old > index.cgi
view README.MAINT @ 407:b2e007c28b8f
Changed ENDS to be ENDSTRUCT instead of ENDSECTION since ENDSTRUCT is required but ENDSECTION is not; updated docs to reflect change
author | lost@l-w.ca |
---|---|
date | Fri, 23 Jul 2010 19:53:43 -0600 |
parents | 219672663ad8 |
children |
line wrap: on
line source
This file is intended for source package maintainers/distributors. This package depends on gnulib, autoconf, automake, and libtool. You will need all these packages installed in order to build from non-release areas in the repository. 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