-
Notifications
You must be signed in to change notification settings - Fork 98
/
RELEASE-PROCESS
139 lines (110 loc) · 5.9 KB
/
RELEASE-PROCESS
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
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
Status
------
This document, at this point, is a proposal only. It attempts to
document how we intend to make the upcoming releases, in order to make
as sure as possible no stupid bugs creep in just before the release.
For the next release, consider getting coverity.com to bugcheck.
(Considered, but the did not respond yet. --hb)
If you try to calculate with 'D' please note this is a spare time project.
Contents
--------
When a new version is about to be released:
0) Day Zero (D+0): The core developers announce their intention of
making a new release. They call for a feature freeze on the Git
HEAD (bug fixes are okay to commit). They also announce the
provisional duration of the freeze before the first release
candidate tarball is about to be made (actual freeze duration may vary for
instance according to the perceived amount of changes since the
last release; for the purpose of this document, it's assumed to be
three days).
Advanced users are encouraged to download the 'git master' or the
snapshot tarballs, and pound on them.
Make sure to check for open Bugzilla bugs with the PATCH keyword.
If there are enough changes that a security audit is appropriate
(e.g. new or changed importers), there is a standing offer from infamous
<[email protected]> to get audits.
1) The core developers agree on the next version number. It's called
$VERSION thereafter. They also look if DIA_PLUGIN_API_VERSION needs
to be updated.
2) D+3: a release candidate tarball is made. It is called
$VERSION-pre1. Simultaneously, a tag is created with the name
"DIA_$VERSION_RELEASE" (with the non-alphanumeric characters in $VERSION
replaced by underscores, e.g.: git tag -a DIA_0_97_PRE3).
$VERSION-pre1 is registered with the Bugzilla, however it is encouraged
that bug reports are made directly (or simultaneously) to the mailing
list.
Please see the section below on how to make a tarball (yes, please do).
Translators, as pulled from the Translation-Team: field in the .po
files, are notified of the upcoming release to give them time to
translate new strings. No further changes to translatable strings
should happen from now till the final release ("string freeze").
Also mail [email protected] to notify the Gnome Translation Project
(and perhaps get new translators).
3a) if a release-critical bug happens before D+10 (say, at D+n), the
release process is paused until the bug is fixed and a new release
candidate tarball $VERSION-pre2 is re-made. Go to either step 3a or
3b with D+10 replaced by D+n+10. Any bugs fixed that way, as well as
further translations, must be transferred back into the main trunk
(cvs update -j).
3b) D+10: if there are no release-critical bugs in the pre-release,
then the same source (fetched from the Git branch) is rebuilt with the
final $VERSION number (and the resulting "new" version is re-tagged
in Git). $VERSION is registered with the Bugzilla, and all
$VERSION-preX are removed (from now on, bugs against -preX are
rejected as INVALID).
A Git branch is created with the name "dia-$VERSION" with the
non-alphanumeric characters in $VERSION replaced by dashes, e.g.:
git checkout -b dia-0-97 && git push dia-0-97
4) once the new release is complete and uploaded, announcements on
freshmeat, the dia web site, the dia mailing list,
[email protected], gnomefiles.org and maybe a gnotices story
(news.gnome.org) are made. Alerting the package maintainers for the
various distributions is also a good idea, get names from MAINTAINERS
and update those who have changed.
5) the Git HEAD freeze is lifted one week /after/ the release is
generally available, unless a release critical bug is discovered in
the release. If the latter is the case, a new, fixed "brown bag" release is
released and announced as soon as possible (extending the one-week
delay on the Git HEAD thaw).
Once the head is lifted, the release branch is considered dead and
should no longer be used.
How to make a tarball
---------------------
1. Update the version number in configure.in, config.h.win32,
doc/{en,eu,pl}/dia.xml. Also update dia.spec when changing
the version number, but not for a change of prerelease number.
2. Add information about things that have changed to the NEWS file.
3. make sure you have up to date build tools installed on the system.
Libtool is an important one, as new releases add support for new
platforms. Also consider updating intltool
4. make sure "make distcheck" runs to completion. With automake >=
1.5, the checks also make sure "make uninstall" removes all files
that got installed.
5. check to see if the tarball builds in normal and --enable-gnome
modes (this task should disapear with the move to 2.0; there is no
reason to have separate dialog and menu code).
6. Upload to ftp.gnome.org. This is basically just scp'ing the
tarball to widget.gnome.org, then running a command like
"install-module dia-0.90.tar.gz", which will create bz2
tarballs, diffs to the previous version, and signal the ftp mirrors
(currently just ftp.gnome.org and planetmirror.com) to synchronise.
Script to update version:
find . -name configure.in -o -name config.h.win32 -o -name dia.xml | xargs sed -i 's/0\.96-pre[0-9]/0.96-pre3/;'
Issues to solve
---------------
agreeing on how to properly handle the case of having only ten two-decimal
place version numbers until we hit 1.0
How do we notify people that a) a prerelease branch is where translation
goes and b) the prerelease branch is dead when it is.
Files
-----
These files need to be updated at every release:
config.h.win32
NEWS
configure.in
doc/{en,pl}/dia.xml
dia.spec (note that the preN should go in release, not ver).
Webpages
--------
Remember to also update the webpages. In particular, the download page,
the NEWS page and the FAQ needs updating.