diff options
author | Michael Roitzsch <mroi@users.sourceforge.net> | 2005-04-25 14:30:14 +0000 |
---|---|---|
committer | Michael Roitzsch <mroi@users.sourceforge.net> | 2005-04-25 14:30:14 +0000 |
commit | 1b91c04bd87124445dabd2c8b9767fffcb27ecdb (patch) | |
tree | 19f97d2ce8c11af02013ca16f68a383811708d5f /doc | |
parent | 03be12b2751ac3ec1a522bb8690e9fa99bb4004b (diff) | |
download | xine-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.release | 6 |
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) |