105 lines
		
	
	
		
			4.5 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			105 lines
		
	
	
		
			4.5 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| How to do a GTK+ release?
 | |
| =========================
 | |
| 
 | |
| Make sure you have suitable versions of autoconf and libtool.
 | |
| Also make sure you have the following packages installed with all their
 | |
| dependencies:
 | |
| * gtk-doc
 | |
| * docbook-utils
 | |
| Without those packages make distcheck will *not* pass.
 | |
| 
 | |
| 
 | |
|  0) Blow away your gtk+ directory, check a new version out
 | |
| 
 | |
|  1) autogen and build it, make sure to enable docs by specifying 
 | |
|     --enable-gtk-doc --enable-man
 | |
| 
 | |
|  2) Update NEWS based on the various ChangeLog files; follow the format
 | |
|     of prior entries. This includes finding noteworthy new features,
 | |
|     collecting summaries for all the fixed bugs that are referenced
 | |
|     and collecting all updated translations. 
 | |
|     Also collect the names of all contributors that are mentioned. 
 | |
|     We don't discriminate between bug reporters, patch writers, 
 | |
|     committers, etc. Anybody who is mentioned in ChangeLog gets
 | |
|     credits, but only real names, not email addresses or nicknames.
 | |
| 
 | |
|  3) In particular, if this is a major, stable, release, verify that
 | |
|     README.in contains the relevant release notes and that the
 | |
|     required versions of dependencies in INSTALL.in are in sync
 | |
|     with configure.in.
 | |
| 
 | |
|  4) Verify that the version in configure.in has been bumped after the last
 | |
|     release. (Note that this is critical, a slip-up here will cause the 
 | |
|     soname to change).
 | |
| 
 | |
|  5) Make sure that make check is happy (If you don't do it here, make distcheck
 | |
|     will also catch it, but it is kind of disheartening to see make distcheck 
 | |
|     fail due to an extraneous symbol after watching it build the docs for an 
 | |
|     hour...). 
 | |
|     Typical problems to expect here (depending on whether this is a devel 
 | |
|     snapshot or a stable release):
 | |
|     * forgotten source files
 | |
|     * new symbols missing from .symbols files
 | |
|     * symbols that are exported by should be private (static or _-prefixed)
 | |
|     * symbols that cause PLT entries. This is either caused by using
 | |
|       a in the same library function without including the header or by
 | |
|       using a function from a different library, which is not yet allowed
 | |
|       by the filter in pltcheck.sh
 | |
| 
 | |
|  6) If this is a devel release, make sure that the docs for new symbols
 | |
|     are in good shape. Look at the -unused.txt files and add stuff found
 | |
|     there to the corresponding -sections.txt file. Look at the 
 | |
|     -undocumented.txt files and see if there is anything in there that
 | |
|     should be documented. If it is, this may be due to typos in the doc
 | |
|     comments in the source. Make sure that all new symbols have proper 
 | |
|     Since: tags, and that there is an index in the main -docs.sgml for 
 | |
|     the next stable version. 
 | |
| 
 | |
|  7) Add === Released 2.x.y === at the top of all ChangeLog files
 | |
| 
 | |
|  8) make distcheck
 | |
| 
 | |
|  9) Fix broken stuff found by 8), repeat
 | |
| 
 | |
| 10) svn commit; you'll have a bunch of po file changes, ChangeLog updates,
 | |
|      and maybe some doc changes too
 | |
|  
 | |
| 11) If 10) fails because someone else committed inbetween, curse, svn up,
 | |
|     fix conflicts and go to 8)
 | |
| 
 | |
| 12) Now you've got the tarball. Check that the tarball size looks
 | |
|     reasonable compared to previous releases. If the size goes down
 | |
|     a lot, likely the docs went missing for some reason. Or the translations.
 | |
|     If the size goes up by a lot, something else may be wrong.
 | |
| 
 | |
| 13) Tag the release. The command for doing that looks like
 | |
| 
 | |
|       svn cp svn+ssh://matthiasc@svn.gnome.org/svn/gtk+/branches/gtk-2-12 \
 | |
|              svn+ssh://matthiasc@svn.gnome.org/svn/gtk+/tags/GTK_2_12_10
 | |
| 
 | |
| 14) Bump the version number in configure.in and commit this change 
 | |
|     with a ChangeLog entry
 | |
| 
 | |
| 15) Upload the tarball to master.gnome.org and run install-module to transfer
 | |
|     it to download.gnome.org. If you don't have an account on master.gnome.org,
 | |
|     find someone who can do it for you. The command for this looks like
 | |
|   
 | |
|       scp gtk+-2.12.10.tar.gz matthiasc@master.gnome.org:
 | |
|       ssh matthiasc@master.gnome.org
 | |
|       install-module gtk+-2.12.10.tar.gz
 | |
| 
 | |
| 16) Get the bz2 tarball and the .md5sum files back from master.gnome.org 
 | |
|     You can probably also create it locally, but I've experienced md5 
 | |
|     mismatches when doing so
 | |
| 
 | |
| 17) Go to the gnome-announce list archives, find the last announce message,
 | |
|     create a new message in the same form, replacing version numbers, 
 | |
|     commentary at the top about "what this release is about" and the 
 | |
|     Summary of changes.
 | |
| 
 | |
| 18) Send it to gnome-announce-list, gtk-list, gtk-app-devel-list and
 | |
|     gtk-devel-list. Set reply-to to gnome-hackers.
 | |
| 
 | |
| 19) Add a link to the release announcement to www.gtk.org which lives 
 | |
|     in the gtk-web cvs module.
 | 
