4 This document, at this point, is a proposal only. It attempts to
5 document how we intend to make the upcoming releases, in order to make
6 as sure as possible no stupid bugs creep in just before the release.
8 For the next release, consider getting coverity.com to bugcheck.
13 When a new version is about to be released:
15 0) Day Zero (D+0): The core developers announce their intention of
16 making a new release. They call for a feature freeze on the CVS
17 HEAD (bug fixes are okay to commit). They also announce the
18 provisional duration of the freeze before the first release
19 candidate tarball is about to be made (actual freeze duration may vary for
20 instance according to the perceived amount of changes since the
21 last release; for the purpose of this document, it's assumed to be
24 Advanced users are encouraged to download the CVS HEAD or the
25 snapshot tarballs, and pound on them.
27 Make sure to check for open Bugzilla bugs with the PATCH keyword.
29 If there are enough changes that a security audit is appropriate
30 (e.g. new or changed importers), there is a standing offer from infamous
31 <infamous41md@sol-biotech.com> to get audits.
33 1) The core developers agree on the next version number. It's called
34 $VERSION thereafter. They also look if DIA_PLUGIN_API_VERSION needs
37 2) D+3: a release candidate tarball is made. It is called
38 $VERSION-pre1. Simultaneously, a CVS branch is made with the name
39 "DIA_$VERSION_RELEASE" (with the non-alphanumeric characters in $VERSION
40 replaced by underscores, e.g. cvs tag -b DIA_0_93_RELEASE).
41 $VERSION-pre1 is registered with the Bugzilla, however it is encouraged
42 that bug reports are made directly (or simultaneously) to the mailing
45 Please see the section below on how to make a tarball (yes, please do).
47 Translators, as pulled from the Translation-Team: field in the .po
48 files, are notified of the upcoming release to give them time to
49 translate new strings. No further changes to translatable strings
50 should happen from now till the final release ("string freeze").
51 Also mail gnome-i18n@gnome.org to notify the Gnome Translation Project
52 (and perhaps get new translators).
54 3a) if a release-critical bug happens before D+10 (say, at D+n), the
55 release process is paused until the bug is fixed and a new release
56 candidate tarball $VERSION-pre2 is re-made. Go to either step 3a or
57 3b with D+10 replaced by D+n+10. Any bugs fixed that way, as well as
58 further translations, must be transferred back into the main trunk
61 3b) D+10: if there are no release-critical bugs in the pre-release,
62 then the same source (fetched from the CVS branch) is rebuilt with the
63 final $VERSION number (and the resulting "new" version is re-tagged
64 in CVS). $VERSION is registered with the Bugzilla, and all
65 $VERSION-preX are removed (from now on, bugs against -preX are
68 4) once the new release is complete and uploaded, announcements on
69 freshmeat, the dia web site, the dia mailing list,
70 gnome-announce-list@gnome.org, gnomefiles.org and maybe a gnotices story
71 (news.gnome.org) are made. Alerting the package maintainers for the
72 various distributions is also a good idea, get names from MAINTAINERS
73 and update those who have changed.
75 5) the CVS HEAD freeze is lifted one week /after/ the release is
76 generally available, unless a release critical bug is discovered in
77 the release. If the latter is the case, a new, fixed "brown bag" release is
78 released and announced as soon as possible (extending the one-week
79 delay on the CVS HEAD thaw).
81 Once the head is lifted, the release branch is considered dead and
82 should no longer be used.
86 1. Update the version number in configure.in, config.h.win32,
87 doc/{en,eu,pl}/dia.xml. Also update dia.spec when changing
88 the version number, but not for a change of prerelease number.
89 2. Add information about things that have changed to the NEWS file.
90 3. make sure you have up to date build tools installed on the system.
91 Libtool is an important one, as new releases add support for new
92 platforms. Also consider updating intltool
93 4. make sure "make distcheck" runs to completion. With automake >=
94 1.5, the checks also make sure "make uninstall" removes all files
96 5. check to see if the tarball builds in normal and --enable-gnome
97 modes (this task should disapear with the move to 2.0; there is no
98 reason to have separate dialog and menu code).
99 6. Upload to ftp.gnome.org. This is basically just scp'ing the
100 tarball to widget.gnome.org, then running a command like
101 "install-module dia-0.90.tar.gz", which will create bz2
102 tarballs, diffs to the previous version, and signal the ftp mirrors
103 (currently just ftp.gnome.org and planetmirror.com) to synchronise.
105 Script to update version:
107 find . -name configure.in -o -name config.h.win32 -o -name dia.xml | xargs sed -i 's/0\.95*/0.95-1/;'
112 agreeing on how to properly handle the case of having only ten two-decimal
113 place version numbers until we hit 1.0
115 How do we notify people that a) a prerelease branch is where translation
116 goes and b) the prerelease branch is dead when it is.
121 These files need to be updated at every release:
127 dia.spec (note that the preN should go in release, not ver).
132 Remember to also update the webpages. In particular, the download page,
133 the NEWS page and the FAQ needs updating.