Developing Freeciv
Coding Remember How to Contribute Bug Reporting Coding Style Commit Rules Source Tree Access Help Wanted Forum Known Bugs Browse Source Tree Testing Tips Release Process
v • d • e

Contents 1 Release process 2 Before the release 2.1 Translations and string freeze 2.2 Preliminary NEWS 3 Making a release 3.1 PO files 3.2 NEWS 3.3 Docs 3.4 Bump version 3.5 ChangeLog 3.5.1 People 3.5.2 Committing 3.6 Tagging 3.7 Mark as release version 3.8 Distcheck 3.9 Upload source archives 3.9.1 Freeciv.org 3.9.2 Sourceforge 3.10 Kick off Windows/Mac binaries 3.10.1 Create tasks in Gna 3.11 Notification 3.11.1 When source tarball is available 3.11.1.1 Freeciv.org 3.11.2 IRC 3.11.3 When binaries are available 3.11.3.1 Email 3.11.4 Forum 3.11.4.1 Twitter 3.11.4.2 Sourceforge 4 Release Candidate

Release process Edit

Freeciv is using subversion branches and tags in the release process. Development of new features take place on the trunk code. When a new feature set on trunk is deemed feature complete enough for general use, the trunk source tree will be branched into a "stable" branch, named with the pattern SX_Y where X_Y is the version number, ex. S2_2. When we're ready to make a public release from the branch, a tag is created with this naming: RX_Y_Z where R stands for "release", X_Y is taken from the branch, and Z is the minor version; ex. R2_2_0.

Before the release Edit

Translations and string freeze Edit

Announce the intention to make a release in plenty of time on freeciv-i18n. Decide on and announce a string freeze policy for the release. For a minor release, a week of frozen strings should usually be sufficient. Betas and release candidates do not require a string freeze.

Preliminary NEWS Edit

It's often a good idea to start preparing the NEWS file ahead of time, if possible. See the guidelines at #NEWS for details.

Making a release Edit

This is the quick checklist for making a release. This applies mostly to minor releases; major releases take a lot more work.

PO filesEdit

Run "make update-po" in the po/ directory. Usually it's best to commit the changes.

NEWSEdit

Make a diff from the previous release version. From this the news can be created. NEWS goes into a wiki page named something like NEWS-2.3.2. (If this has been started before the day of the release, make sure it's up to date.)

For the first release from a new major branch (likely a "beta1"), create a NEWS-x.y.0 file describing changes since the previous stable branch. This is a major undertaking. List only notable new features and major bugfixes since the previous major branch, not every single change. Don't include changes that are likely to appear in a future release from the previous branch. This file should be reasonably accurate "what's new in 2.3.x compared to 2.2.y" for all x and y.

For all other (minor) releases, the NEWS-x.y.z file should usually account for every change, although minor fixes can often be grouped under headings like "memory leak fixes" or "help improvements". In the beta/RC cycle leading up to x.y.0, make sure NEWS-x.y.0 stays up to date as well.

Remember to add this page to Category:NEWS and link to it from NEWS!

DocsEdit

For a major release only: Update the NEWS file in svn to reflect the major version, and link to the relevant NEWS-x.y.0 on wiki.

Bump versionEdit

(Be sure you're going to complete the release the same day before committing this...)

Edit version.in (or fc_version for S2_3 onwards) and bump the version number. Ensure that there's still a '+' (plus) to indicate non-release code. Commit this to the branch.

ChangeLogEdit

Updating the ChangeLog in svn can be done through the svn log command. Do something like svn log -v -r xxxxx:yyyyy where xxxxx is the last revision as of branching/tagging and yyyyy is the revision after the one at the top of the current changelog. Paste the output into the top of the ChangeLog file.

PeopleEdit

The People page can be updated from the new ChangeLog, as needed.

CommittingEdit

The ChangeLog should be the very last thing to be committed before the release, so that it includes info about all the other commits.

TaggingEdit

Copy the branch into a tag. Something like:

svn copy svn+ssh://[username]@svn.gna.org/svn/freeciv/branches/S2_1 svn+ssh://[username]@svn.gna.org/svn/freeciv/tags/R2_1_0_beta1

should do the trick.

Tag is the release, not copy of it. It's preferred that tarball is built from clean tag checkout.

Mark as release versionEdit

Check out the tag as you would a regular branch.

Edit version.in (or fc_version for S2_3 onwards) and remove the '+' (plus), to indicate that this is release code. Commit this to the tag.

DistcheckEdit

Run make distcheck in the root of the source dir and make sure there are no serious errors.

(Since this is a clean checkout, you'll need to run ./autogen.sh and make first.)

Upload source archivesEdit

Freeciv.orgEdit

First compile the source code with "make" then create a .tar.gz via "make dist". Upload this to download.gna.org. Put a copy in /upload/freeciv/stable - e.g. scp freeciv-2.3.2.tar.gz [username]@download.gna.org:/upload/freeciv/stable/. (Betas and release candidates go in /upload/freeciv/beta instead.)

Untar the original and zip it up: "tar xzf freeciv-2.3.2.tar.gz; zip -r freeciv-2.3.2.zip freeciv-2.3.2". Then ungzip the original and bzip2 it: "gunzip freeciv-2.3.2.tar.gz && bzip2 --best freeciv-2.3.2.tar" (take a copy of the .tar.gz first). Copy both of these files into the same directory as before.

Now update the MD5SUM file. Download it from the server, add the sums for the three archives (something like md5sum freeciv-2.3.2.* >> MD5SUM), and re-upload it.

SourceforgeEdit

Upload the files to Sourceforge. This takes a bit of doing. Log in with your account on their website, go to our project page, and go to the Files page where you create a new folder for the release, e.g. /Freeciv X.Y/X.Y.Z/ .

Next, upload the release packages to the folder you just created. Then you have two options to upload the files: through a file transfer app such as scp, or through a web browser. For the former, do something like scp freeciv-X.Y.Z.tar.gz [username],freeciv@frs.sourceforge.net:"/home/frs/project/f/fr/freeciv/Freeciv\ X.Y/X.Y.Z/"; for the latter, use the "Add Files" option in the web interface using a modern web browser.

When you're done, click "Files" at the top right of the page to make sure the release is there.

Use the web UI to mark the .tar.bz2 as the Default Download for Linux, BSD, Solaris, and Others (leaving Windows and Mac OS X alone; they'll be updated when the package maintainers upload their binaries).

Kick off Windows/Mac binariesEdit

Having made the source tarball, it's time for the package maintainers to do their thing.

Create tasks in GnaEdit

Create a task at Gna to track each of:

• The Windows package, maintained by cproc at time of writing. (Example.)
  • (Here are some notes on how the Windows package is built.)
• The Mac OS package, maintained by bitaxis at time of writing. (Example.)

(The appearance of these tasks shouldn't come as a complete surprise to the package maintainers, of course.)

NotificationEdit

Notification goes in several places.

At the moment, we try to postpone some notifications until binary packages are available, for a day or two after upload of the source tarball, since most users will want the binaries.

When source tarball is availableEdit

i.e., immediately after the above:

Freeciv.orgEdit

Edit Template:News to add the news. Also edit News archive, per the instructions there, including moving to the appropriate yearly-news page, e.g., 2010, if this is the first news this year. Release announcements are pretty dull so it's easy to just copy an old one and change the versions and dates. (If binaries aren't available at the time of doing this, just say "Binary versions for other platforms will be listed as they become available" or some such.)

Also, change Template:Version and Template:Released to the correct version and date, and update Main Page to reflect the versions that are now available. Finally, update the files on Download to point to the correct version (leave the binaries to be changed later, but make sure that it's clear which version of the binaries is currently available).

You should, of course, test one or more of the download links from Template:News and Download.

IRCEdit

Change the topics of #freeciv and #freeciv-dev with the new version.

When binaries are availableEdit

EmailEdit

Email should go to freeciv-dev@freeciv.org and freeciv-announce@freeciv.org. Use bcc on all of them with reply-to to freeciv-dev (we don't want others spamming these lists with replies). The email is basically a text version of the news from the web site.

ForumEdit

Start a new thread at the Announcements forum.

TwitterEdit

Twit about the new release @freeciv.

SourceforgeEdit

Double-check the binaries are marked as being the latest file for their platforms, if appropriate. (Package maintainers will probably already have done this when they uploaded.)

Release CandidateEdit

A major release leaving beta stage should be preceded by at least one release candidate (RC). The final release is made in the case no (new) showstopper bug is discovered within 7 (seven) days. If a showstopper bug is discovered, this bug should be fixed and a second release candidate should be released as soon as possible. Repeat until a full seven-day period can be completed.

The definition of a showstopper bug is one that prevents a large group of players to build, start, or complete the game.

During the release candidate phase, any code or rules changes are strongly discouraged. On the other hand, updates to documentation and translations are equally strongly encouraged.