RELEASE-PROCESS 5.9 KB
Newer Older
1 2 3 4 5 6 7
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.

8
For the next release, consider getting coverity.com to bugcheck.
9 10 11
(Considered, but the did not respond yet. --hb)

If you try to calculate with 'D' please note this is a spare time project.
12

13 14 15 16 17
Contents
--------

When a new version is about to be released:

18
0) Day Zero (D+0): The core developers announce their intention of
19
   making a new release. They call for a feature freeze on the Git
20 21 22 23 24 25 26
   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).

27
   Advanced users are encouraged to download the 'git master' or the
28 29
   snapshot tarballs, and pound on them.

Lars Clausen's avatar
Lars Clausen committed
30 31
   Make sure to check for open Bugzilla bugs with the PATCH keyword.

32 33 34 35
   If there are enough changes that a security audit is appropriate
   (e.g. new or changed importers), there is a standing offer from infamous
   <infamous41md@sol-biotech.com> to get audits.

36
1) The core developers agree on the next version number. It's called
37 38
   $VERSION thereafter. They also look if DIA_PLUGIN_API_VERSION needs
   to be updated.
39

40
2) D+3: a release candidate tarball is made. It is called
41
   $VERSION-pre1. Simultaneously, a tag is created with the name
42
   "DIA_$VERSION_RELEASE" (with the non-alphanumeric characters in $VERSION
43
   replaced by underscores, e.g.: git tag -a DIA_0_97_PRE3).
44 45 46
   $VERSION-pre1 is registered with the Bugzilla, however it is encouraged
   that bug reports are made directly (or simultaneously) to the mailing
   list.
47

48 49
   Please see the section below on how to make a tarball (yes, please do).

Lars Clausen's avatar
Lars Clausen committed
50 51 52 53
   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").
54 55
   Also mail gnome-i18n@gnome.org to notify the Gnome Translation Project
   (and perhaps get new translators).
Lars Clausen's avatar
Lars Clausen committed
56

57 58 59
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
60 61 62
   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).
63

64
3b) D+10: if there are no release-critical bugs in the pre-release,
65
   then the same source (fetched from the Git branch) is rebuilt with the
66
   final $VERSION number (and the resulting "new" version is re-tagged
67
   in Git). $VERSION is registered with the Bugzilla, and all
68 69
   $VERSION-preX are removed (from now on, bugs against -preX are
   rejected as INVALID).
70
   A Git branch is created with the name "dia-$VERSION" with the 
71
   non-alphanumeric characters in $VERSION replaced by dashes, e.g.: 
72
   git checkout -b dia-0-97 && git push dia-0-97
73

74
4) once the new release is complete and uploaded, announcements on
75
   freshmeat, the dia web site, the dia mailing list,
Lars Clausen's avatar
Lars Clausen committed
76
   gnome-announce-list@gnome.org, gnomefiles.org and maybe a gnotices story
Lars Clausen's avatar
Lars Clausen committed
77 78 79
   (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.
80

81
5) the Git HEAD freeze is lifted one week /after/ the release is
82 83 84
   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
85
   delay on the Git HEAD thaw).
86

87 88 89
   Once the head is lifted, the release branch is considered dead and
   should no longer be used.

90 91
How to make a tarball
---------------------
Lars Clausen's avatar
Lars Clausen committed
92
  1. Update the version number in configure.in, config.h.win32,
93
     doc/{en,eu,pl}/dia.xml.  Also update dia.spec when changing
Lars Clausen's avatar
Lars Clausen committed
94 95 96
     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.
97
      Libtool is an important one, as new releases add support for new
Lars Clausen's avatar
Lars Clausen committed
98 99
     platforms.  Also consider updating intltool
  4. make sure "make distcheck" runs to completion.  With automake >=
100 101
     1.5, the checks also make sure "make uninstall" removes all files 
     that got installed.
Lars Clausen's avatar
Lars Clausen committed
102
  5. check to see if the tarball builds in normal and --enable-gnome
103 104
     modes (this task should disapear with the move to 2.0; there is no
     reason to have separate dialog and menu code).
Lars Clausen's avatar
Lars Clausen committed
105
  6. Upload to ftp.gnome.org.  This is basically just scp'ing the
106
     tarball to widget.gnome.org, then running a command like
Lars Clausen's avatar
Lars Clausen committed
107 108 109
     "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. 
110

Lars Clausen's avatar
Lars Clausen committed
111 112
Script to update version:

Lars Clausen's avatar
Lars Clausen committed
113
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/;'
Lars Clausen's avatar
Lars Clausen committed
114

115 116 117
Issues to solve
---------------

118 119
agreeing on how to properly handle the case of having only ten two-decimal
place version numbers until we hit 1.0 
Lars Clausen's avatar
Lars Clausen committed
120

121 122 123
How do we notify people that a) a prerelease branch is where translation
goes and b) the prerelease branch is dead when it is.

Lars Clausen's avatar
Lars Clausen committed
124 125 126 127 128 129
Files
-----

These files need to be updated at every release:

config.h.win32
130
NEWS
Lars Clausen's avatar
Lars Clausen committed
131
configure.in
132 133
doc/{en,pl}/dia.xml
dia.spec (note that the preN should go in release, not ver).
Lars Clausen's avatar
Lars Clausen committed
134 135 136 137 138 139

Webpages
--------

Remember to also update the webpages.  In particular, the download page,
the NEWS page and the FAQ needs updating.