Difference between revisions of "Dev:Release"

Revision as of 13:27, 13 October 2008

Preparation

To do a release you must have a proper up to date copy of the sourcecode. Check out here to see how to obtain it.

You have to be an administrative member of sourceforge and to have write access to the synfig subversion. Ask any of the current administrators about that. Also a wiki account and a forum account are necessary.

We would assume that the svn local copy of the source code are in a separate folder in your local drive and they are: etl, synfig-core, and synfig-studio accordingly to the source code instructions.

Splash

• Pick a date at least 5 weeks into the future.
• Post a splash screen challenge in the forums.
• After 4 weeks, close the challenge and post a poll.
• After one week close the poll and name the winnar!
• Obtain the source of the winner file and commit it:
  • Rename the synfig-studio/images/splash-screen.sifz to synfig-studio/images/splash-xx.xx.xx.sifz where xx.xx.xx is the previous version.
  • Add the new splash source file to synfig-studio/images/splash-screen.sifz
  • Modify synfig-studio/images/Makefile.am accordingly.
  • Update synfig-studio/AUTHORS, synfig-studio/README, and synfig-studio/src/gtkmm/about.cpp if needed.

Froze commits

It would be good if no one commit more changes/patches until the release is done. Mainly because at some point we need to stop polishing the current revision.

Ping coders, artists and translators and advice them about the release preparation. Ask for last updates before froze the commits. Give some time to update. Preferably no more than a week.

Copyrights

Make sure the copyrights in README, the AUTHORS file and the about dialog list of contributors are up to date.

Do a grep -r Copyright ./ in the three etl, synfig-core and synfig-studio folders. It would return all the poeple that have current copyrights. Review the list of commits and the patches authoring to update it properly. Don't forget the artists and translators.

Versioning

• Finalise the dates and SVN ids in NEWS.
  • You already know the release revision number and the date of the next commit. Place them correctly in the etl/NEWS, synfig-core/NEWS and synfig-studio/NEWS files.

• Bump version numbers and ETL/synfig dependencies in the configure.ac files.
  • This would imply increase the version number in the following files:
    • etl/configure.ac: increase ETL version number
    • synfig-core/configure.ac: increase ETL version number dependence matching the previous one and the synfig version number.
    • synfig-studio/configure.ac: Increase ETL and synfig version number dependence matching the previous ons and the synfigstudio version number.

• Double check the version numbers in configure.ac and NEWS are correct. Fix them if are wrong.

• Double check the copyright years in the README files and the about dialog are correct. Fix them if are wrong.

Create the tarball

 mkdir ~/tmp/synfig-release

 cd ~/tmp/synfig-release
 svn export https://synfig.svn.sourceforge.net/svnroot/synfig/ETL/trunk/ etl
 cd etl
 autoreconf -if
 ./configure
 make distcheck
 tar xf ETL-0.04.12.tar.gz
 cd ETL-0.04.12
 ./configure
 make install

 cd ~/tmp/synfig-release
 svn export https://synfig.svn.sourceforge.net/svnroot/synfig/synfig-core/trunk/ synfig
 cd synfig
 libtoolize --ltdl --copy -f
 autoreconf -if
 ./configure
 make distcheck
 tar xf synfig-0.61.09.tar.gz
 cd synfig-0.61.09
 ./configure
 make install

 cd ~/tmp/synfig-release
 svn export https://synfig.svn.sourceforge.net/svnroot/synfig/synfig-studio/trunk/ synfigstudio
 cd synfigstudio
 autoreconf -if
 ./configure
 make distcheck
 tar xf synfigstudio-0.61.09.tar.gz
 cd synfigstudio-0.61.09
 ./configure
 make install

Test before send to SF

• Test installed stuff. At this point there should be some battery of tster sifz files and scripts to run various error proof tests to be sure that the release don't have nasty bugs. Share the tarball with other people that have other OS and ask them to build and run the same tests. There is not exact procedure for that. Maybe contact the People and ask them to do that job. This point is important for testing the release in different platforms, specially if there has been some changes that can have cross effects.

Make tags

• Make tags and update the unstable branch. At the

Release notes

• Write release notes based on the NEWS files. This would imply produce a new version at Releases page and its short versions (for example: Releases/0.61.08-Intro.en) to be sent to sf.net and freshmeat.net.

Upload tarballs to sourceforge.

Update the topic in the irc channel.

Update the Download, Releases, News/Draft, front, News, Roadmap, FAQ pages.

Update the artwork of the MainPage and release all the editable graphics in this page

Ping Atrus/pxegeek to download the tarballs, build windows versions and upload them to sourceforge.

Ping distros to upgrade their packages:

• fink: htodd
• Debian: pabs3 and KiBi
• Fedora: mwiriadi

Post a release announcement on the forums, sourceforge and get PaulWise (pabs) to update freshmeat and gnomefiles.org.

Send a short writeup to the folks at LWN.net and the mailing lists.

Celebrate with a nice $BEVERAGE_OF_CHOICE

Start thinking about the Roadmap for the next release.

A week or two later, check that all the unofficial packages have been updated, if not ping them and move them to the old versions section. Also check the svn versions are recentish and if not move them to the old versions section.