Difference between revisions of "Dev:Release"

From Synfig Studio :: Documentation
Jump to: navigation, search
(remove url)
(save for security)
Line 2: Line 2:
 
[[Category:Building]]
 
[[Category:Building]]
  
Basic process run-down, will fix up later:
+
==Preparation==
  
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.
+
== 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!
  
After one week close the poll and name the winnar!
+
== 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.
  
 +
==Copyrights==
 
Make sure the copyrights in README, the AUTHORS file and the about dialog list of contributors are up to date.
 
Make sure the copyrights in README, the AUTHORS file and the about dialog list of contributors are up to date.
  
Bump version numbers and ETL/synfig dependencies in the configure.ac files.
+
==Release procedure==
  
Finalise the dates and SVN ids in NEWS.
+
*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.
  
Double check the version numbers in configure.ac and NEWS are correct.
+
*Bump version numbers and ETL/synfig dependencies in the configure.ac files.
 +
**This would imply increase the version number in the following files:
  
Double check the copyright years in the README files and the about dialog are correct.
+
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
 
   mkdir ~/tmp/synfig-release
Line 58: Line 74:
 
   make install
 
   make install
  
Test installed stuff.
+
== 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|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 and update the unstable branch.
+
  
Write release notes based on the NEWS files.
+
== 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.
 
Upload tarballs to sourceforge.

Revision as of 12:54, 13 October 2008


Preparation

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!

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.

Copyrights

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

Release procedure

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