Dev:Release

Preparation

Choose a release manager (RM) who will manage the release and do most of the work and co-ordination needed to get a release out.

The RM must have a proper up to date copy of the sourcecode. Check out here to see how to obtain it.

The RM must 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.

Freeze 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.

First should come the feature freeze, then the string freeze and then the final cutoff of translations & bug fixes just before the release.

There is no technical way to freeze commits with sourceforge, so the developers should be willing to play nice with the release.

Ping coders, artists and translators and advice them about the release preparation. Ask for last updates before freezing 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 README 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. Review the AUTHORS in each folder and don't forget the artists and translators.

Release candidates

Following the this instructions to create a tarball of the current svn release, upload them to sourceforge and tag them as Release Candidate number 1, 2 etc. Create as many Release candidates as you need or consider. Ask people to download and test them. The forum and the IRC is a good place. When everything goes fine then continue the release.

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

Create a tarball to allow users to just compile and install. Run the following commands and substitute the XX versions properly. For example for etl the numbering is nowadays 0.04.12 and for synfig and synfigstudio numbering are nowadays 0.61.09. Some day we should decide what do to with version numbering.

• This would prepare the environment variables to the correct values. local-synfig is the place where you would install the binary after test its installation.

 export PREFIX="$HOME/local-synfig"
 export PKG_CONFIG_PATH="$PKG_CONFIG_PATH:$PREFIX/lib/pkgconfig"
 export PATH="$PREFIX/bin:$PATH"

• This creates a temporary working folder to download the source and create the tarballs.

 mkdir ~/tmp
 mkdir ~/tmp/synfig-release

• This creates the etl tarball and install it.

 version=0.04.12
 cd ~/tmp/synfig-release
 svn export https://synfig.svn.sourceforge.net/svnroot/synfig/ETL/trunk/ etl
 cd etl
 autoreconf -if
 ./configure --prefix="$PREFIX"
 make distcheck
 tar xf ETL-${version}.tar.gz
 cd ETL-${version}
 ./configure --prefix="$PREFIX"
 make install

• This creates the synfig tarball and install it.

 version=0.61.09
 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 --prefix="$PREFIX"
 make distcheck
 tar xf synfig-${version}.tar.gz
 cd synfig-${version}
 ./configure --prefix="$PREFIX"
 make install

• This creates the synfigstudio tarball and install it.

 version=0.61.09
 cd ~/tmp/synfig-release
 svn export https://synfig.svn.sourceforge.net/svnroot/synfig/synfig-studio/trunk/ synfigstudio
 cd synfigstudio
 autoreconf -if
 ./configure --prefix="$PREFIX"
 make distcheck
 tar xf synfigstudio-${version}.tar.gz
 cd synfigstudio-${version}
 ./configure --prefix="$PREFIX"
 make install

Test before send to SF

• Test installed stuff. To run the installed synfigstudio from the tarball you've created you have to run directly from the command line:

$PREFIX/bin/synfigstudio

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 each {etl, synfig-core, synfig-studio} folders run the following commands:

make tagstable
make tagrelease

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

• Upload tarballs to sourceforge.
  • Upload the three tarballs to SF by using the online upload or following the instructions from this link
  • Create a new release at sf.net following the instructions of this link

Update the rest of stuff

• 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 pixelgeek 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.