Releases

When you are releasing your addon, there are special procedures that you should follow. Fortunately, this page explains what those procedures are and how to perform them. Also, this page talks about the use of some special services and tools that are part of the releasing process.

The Release Process

When you wish to release your addon, you should tag your release. In the context of Subversion, a tag is essentially a time capsule; it stores your addon in the form it had at the time of the tagging. Due to this, you should not commit any changes to a tag unless you are smiting a horrible mistake in the tag, such as the entire addon being stored in a subdirectory of the tag.

Pre-tag

Before you even think about releasing, be sure to give your addon a final pre-release sanity check.

After making any final changes and sanity checks, bump version numbers in things such as changelogs, _main.cfg, and—especially—the VERSION tag. When you bump version numbers, be sure to remove particles such as +svn and -svn.

Tagging

Make sure that your addon has a tags tree in the appropriate place. For example, if you are releasing Son_of_Haldric from /trunk, make sure that a Son_of_Haldric directory exists in /tags/trunk.

Now, enter, replacing the content within the brackets as necessary:

svn copy https://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/<path_to_addon> https://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/tags/<path_to_addon>/<version_number>

You may give svn copy an -r (revision_number) argument to ensure that no one’s commits affect the result of your svn copy run.

Post-tag

Either build archives and release from the source (/trunk or /branches) or the tag that you just made.

After you tag your release, do a post-release bump on all of the version numbers that you bumped before you tagged the release. In other words, readd the particles that you removed before you tagged.

Packaging tools

Many addons in Wesnoth-UMC-Dev are packaged with shadowmaster’s poorly designed—and documented—build-external-archive.sh. However, this tool and its architecture is deprecated; due to this, we suggest that new users wait until umcdist has been completed and is ready for production.

The script not only produces tarballs, but MD5 sums, SHA1 sums, and XDelta patches.

Once the replacement umcdist tool is ready, descriptions of any required configuration files, and instructions on using umcdist will be added to this page.

dist and metatags

The dist directory and its contents are required if you want to your addon to be compatible with build-external-archive.sh. The dist directory is to be placed at the root of your addon’s directory. Although the only essential metatags—as well as the ones that are actually part of build-external-archive.sh’s processes—are BASEDIRS and VERSION, we shall explain the purpose and contents of all of the metatags.

Metatags are to only contain the information listed in the explanations.

Using build-external-archive.sh

The syntax of build-external-archive.sh is as follows: build-external-archive.sh [--force | -f] [{--xdelta | -x} (older version)] (campaign’s local root) (output dir)

When actually running the command, do not include any brackets or parentheses.

The --force/-f option makes it so that the script ignores anything that may be overwritten. The --xdelta/-x option makes the script generate XDelta patches; requires xdelta to be installed. The (older version) placeholder represents the version number found in the filename of the tarball of the previous file The --no-svn-export/-E option tells the script not to see if the target directory is an SVN checkout, thus any .svn directories will go into the generated tarball. The (campaign’s local root) placeholder represents the addon’s directory name. Finally, the (output dir) placeholder represents where the generated files will be sent.

Example: build-external-archive.sh -x 0.3.0 Son_of_Haldric .

The code above essentially tells build-external-archive.sh to build a tarball of the addon contained in Son_of_Haldric and generate an XDelta patch against version 0.3.0 while placing the generated files in the working directory.

For more information on build-external-archive.sh, refer to the script itself.

The File Release System

As you may know, SourceForge.net, our service provider, offers a File Release System (FRS) service, which Wesnoth-UMC-Dev uses to host tarballs of user-made content releases and XDelta patches that may be used to upgrade packages from one release to another.

Getting write access

The developers with read/write access to the FRS directories are the release technicians.

By default, only admins and half-admins have read/write access to the FRS directories; however, we shall grant access to the FRS to anyone who requires it and qualifies for such privileges. To see if you qualify, ask one of our admins or half-admins; be sure to present your case when you ask.

Note that one add-on may have multiple release technicians if it is required. It is not required for an add-on’s release technician to also be its current lead maintainer.

Policies

The only uploads that will be accepted are the following:

The preferred format is tar archives compressed using bzip2 (.tar.bz2) or gzip (.tar.gz). Since the bzip2 compression algorithm tends to provide better savings with large amounts of text files and that binary files do not impact the resultant file’s size too much, it is preferred over gzip.

Although you can choose your own packaging format as long as there are free and open-source tools capable of unpacking your uploads, we recommend that you stick to one unique format to avoid confusing your players.

The project policies and the terms of the OSD-compliant license you choose for your packages still apply.

Administrative uploads

If you do not have access to the FRS and wish to have your content uploaded to SourceForge, you may Espreon to upload your content for you.

Administrative uploads are generated with the help of the build-external-archive.sh script. The admin or half-admin in charge of your package will create a dist directory in your add-on’s tree and a few special files. Do not modify these files unless you know what you are doing.

Regular uploads

If you are given access to the file release system, you will first have to learn how to use it, if you have not already done so.

Creating a package directory

If your add-on already has a package directory of its own, then you may skip this section.

In order to get to the package/release management page, first go to Wesnoth-UMC-Dev’s "Develop" page. Move your cursor to "Project Admin"; click "File Manager".

Left-click the / directory’s gear icon; click "New folder". Afterwards, enter your addon’s name and hit enter.

Uploading

Left-click your addon’s gear icon, click "New folder", enter the release’s version number, and hit enter. Afterwards, left-click the release’s directory, click "Upload here," point the file selection dialog to a file, and repeat until all of your files have been uploaded.

Post-upload

Left-click your package’s archive; on the right side of the screen, a box titled "File Details" should have appeared. Under "Platform", click "Select All".

Next, append your addon’s directory and the release number to this URL: https://sourceforge.net/projects/wesnoth-umc-dev/files/

Say that we are releasing version 0.4.0 of Son of Haldric; the URL would become https://sourceforge.net/projects/wesnoth-umc-dev/files/Son of Haldric/0.4.0/

Finally, add the resulting URL to your release’s post.

Generated in 0.003 seconds.
This page was last modified on Mon Dec 06 05:45:36 CET 2010.