diff lwlink/tags/1.0/README.MAINT @ 136:72d8c84a8734

Release 1.0
author lost
date Tue, 27 Jan 2009 05:54:10 +0000
parents
children
line wrap: on
line diff
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/lwlink/tags/1.0/README.MAINT	Tue Jan 27 05:54:10 2009 +0000
@@ -0,0 +1,39 @@
+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.
+
+Any branch not directly intended to be a release need not include the
+autotool 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.
+
+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