summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorMichael Roitzsch <mroi@users.sourceforge.net>2005-04-25 14:30:14 +0000
committerMichael Roitzsch <mroi@users.sourceforge.net>2005-04-25 14:30:14 +0000
commit1b91c04bd87124445dabd2c8b9767fffcb27ecdb (patch)
tree19f97d2ce8c11af02013ca16f68a383811708d5f /doc
parent03be12b2751ac3ec1a522bb8690e9fa99bb4004b (diff)
downloadxine-lib-1b91c04bd87124445dabd2c8b9767fffcb27ecdb.tar.gz
xine-lib-1b91c04bd87124445dabd2c8b9767fffcb27ecdb.tar.bz2
**BUGFIX**
add a note on the branches CVS patchset: 7493 CVS date: 2005/04/25 14:30:14
Diffstat (limited to 'doc')
-rw-r--r--doc/internal/HOWTO.release6
1 files changed, 6 insertions, 0 deletions
diff --git a/doc/internal/HOWTO.release b/doc/internal/HOWTO.release
index 8b7077691..10274fbaf 100644
--- a/doc/internal/HOWTO.release
+++ b/doc/internal/HOWTO.release
@@ -54,6 +54,12 @@ Currently, best practice to get a release out looks like this:
3) Versioning
+ You should already know by now, from which branch of CVS the release is
+ going to be made. The current scheme is to have a stable branch from
+ which the subminor releases like 1.0.1, 1.0.2,... are made and an
+ unstable branch in CVS head, which is going to become the next minor
+ (1.1) or major (2.0) xine-lib version.
+
Make sure you know
- what the new release should be called
(the "marketing version" part of the tarball name, for example)