diff options
Diffstat (limited to 'doc/internal')
| -rw-r--r-- | doc/internal/HOWTO.release | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/doc/internal/HOWTO.release b/doc/internal/HOWTO.release index 38532aac0..2e2adff94 100644 --- a/doc/internal/HOWTO.release +++ b/doc/internal/HOWTO.release @@ -59,7 +59,7 @@ Currently, best practice to get a release out looks like this: 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) @@ -88,11 +88,11 @@ Currently, best practice to get a release out looks like this: - does it have the right name? - does it unpack, compile and install correctly? note: make sure to build with as many features as possible - on a Debian box, "apt-get build-dep xine-lib" and + on a Debian box, "apt-get build-dep xine-lib" and "dpkg-buildpackage -rfakeroot" are a good way to do that - test the candidate (and make sure you are running exactly the new version!) This should at least cover the [standard test parcours] - + If you find any errors: fix them (get help on xine-devel or #xine) and go back to step 4) @@ -129,7 +129,7 @@ hands. 12) write the announcement for xine-project.org: You need to have an account on alioth.debian.org and a checked-out copy - of ssh://hg.debian.org//hg/xine-lib/xine-project-www/ (using Mercurial). + of ssh://hg.debian.org//hg/xine-lib/xine-project-www/ (using Mercurial). Add the new news item near the top of pages/news/items.xml (use the provided template), run update.sh (requires xsltproc; if this fails, re-edit), check that it looks fine in a convenient browser, then commit |