From 1b91c04bd87124445dabd2c8b9767fffcb27ecdb Mon Sep 17 00:00:00 2001 From: Michael Roitzsch Date: Mon, 25 Apr 2005 14:30:14 +0000 Subject: **BUGFIX** add a note on the branches CVS patchset: 7493 CVS date: 2005/04/25 14:30:14 --- doc/internal/HOWTO.release | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'doc') 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) -- cgit v1.2.3