1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
Make the following directories:
clean sources-old sources dirty
and optionally:
test build done
Choose version number:
* remember that RPM is stupid and considers 5.0beta1 newer than
5.0, so always use "code versions" for the packages. Also
stuff like "-" etc is not working, so omit it
Checkout branch:
fix the paths in versions script
use the checkout script
clean up the cache/ directory from previous builds
Update version number
* */*.lsm
* arts/configure.in.in
* kdewebdev/quanta/src/quanta.h
* kdevelop/configure.in.in
* kdebase/konqueror/version.h
* kdebase/startkde
* kde-common/admin/cvs.sh has VERSION="3.x.x"
* kdelibs/kdecore/kdeversion.h
* kdelibs/kdecore/ksycoca.h --> ksycoca version number
* kdelibs/README
* kdenetwork/kopete/libkopete/kopeteversion.h
* bugs/template/wizard/report.html.tmpl
* bugs/bugz/wizard_config.pl
* www/areas/enterprise/bizcase/form.inc (major KDE versions only)
* for koffice: configure.in.in, lib/kofficecore/kofficeversion.h, etc.
* common and versions scripts
Update kdepackages in kdelibs/kdeui
Run "fixuifiles"
Make sure the meinproc in path is a version of the correct branch
Use tag_all to get clean sources into "clean" directory (e.g. <releasedir>/clean/koffice)
Make tarballs using "pack <module>". Start with kde-i18n. Do kdelibs/kdebase last.
If you have to redo a tarball because of a code change and don't want to wait for meinproc to complete,
extract the old tarball inside cache/<module> before calling "pack". The docu script will
then use the version from the cache instead of regenerating it, saving a lot of time.
Upload tarballs to their final location, as 'ftprelease' user under a src/ directory.
chmod o-rwx any new dir (so that they're not yet public)
chmod g+w the new directory where packagers will put their files
create contrib/ directory and make it g+w for group "packager"
Test tarballs
md5sum *.tar.bz2 kde-i18n/*.tar.bz2 > MD5SUMS
gpg --detach-sign -a MD5SUMS (if you're bored, do it for all files)
(Note: for KOffice, MD5SUMS should be signed with --clearsign instead of --detach-sign.)
Prepare a Changelog
Inform the packagers (kde-packager at kde dot org)
Ask for/write announcement (on the kde-promo mailing-list)
When everything is ready:
- Make directory on the FTP site readable, so that mirrors can start getting it
Update latest and/or {koffice,kdevelop}-latest symlinks on the FTP site
- clean up the older releases. Make sure that kdestableftp and kdeunstableftp
remain in their advertised size limits (~20 GB). Sort out older binary packages,
add compatibility links.
- Enable syncing during the night, so that the uplink can be saturated and
does not affect interactive server load and network traffic.
- Pre-notify sysadm@trolltech.com and sysadmin@kde.org about an upcoming release
so that they can be ready for fixing bandwidth problems, server outages or similiar.
Its not uncommon that slashdotting affects our server structure, and the right
people have to know about the release date and time to be able to react in time.
When most of the mirrors behind http://download.kde.org have updated:
Commit announcement (after adding PHP header/footer)
Add an entry to www/index.php, www/announcements/index.php, www/info/releases.php,
www/download/index.php and www/whatiskde/project.php
Post announcement in text to kde-announce@kde.org
Post news bit to
* dot.kde.org (editors@kdenews.org)
* freshmeat.net
* newsgroups, optionally
|
