Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Fetching contributors…

Cannot retrieve contributors at this time

146 lines (124 sloc) 6.31 KB
How to make a spring release
1) Make sure to be on branch develop,
on a commit that is on the main repo already.
2) Create the release branch:
git checkout -b release
git push origin release
From now on, EVERYTHING that should to be in the release,
has to be commited on this branch.
3) Write & update the change-log (doc/changelog.txt)
4) Possibly add fixes
~) You may want to merge the release branch into develop from time to time:
git checkout develop
git merge release --no-ff
Release Time
1) Merge the release branch into master:
git checkout master
git reset --hard origin/master
git merge release --no-ff
2) Tag the release:
export REL_VERS=85.0
git tag -a -m "${REL_VERS} release [changed APIs: Lua, unitsync, AI]" ${REL_VERS}
Make sure it looks correct:
gitk master develop release &
3) Create the source-packages (note: this even works if you got unindexed files in your repo, it creates a repo clone to gen the package):
4) Merge the release branch into develop:
git checkout develop
git fetch
git stash
# Do not forget this, somewhen later:
#git stash pop
git rebase origin/develop
git merge release --no-ff
5) Tag the develop branch:
git tag -a -m "dev version after the ${REL_VERS} release" ${REL_VERS}.1
7) POINT OF NO RETURN: Push to the main repo (and delete the release branch):
git push --tags origin develop :release master
9) Force build of the master branch on the windows and the OS-X buildbots.
The later will take long to complete, one hour or more!
10) Write the news post for the frontpage, while waiting for the
buildbot to compile the master branch.
11) Check if everything went fine on and fetch these archives:
12) you should now have these files:
* spring_${REL_VERS}.exe
* spring_${REL_VERS}
* spring_${REL_VERS}_portable.7z
* spring_${REL_VERS}_src.tar.gz
* spring_${REL_VERS}_src.tar.lzma
Upload them to SF (replace USER with your SF account name):
rsync --progress -h -e ssh spring_${REL_VERS}* USER,${REL_VERS}/
13) Post the news post.
14) download page mirror links:
Ask someone with access to to put spring_${REL_VERS}* stuff there.
15) After 1 or 2 days, enforce it on the server, if it is a sync relevant change.
Enforcing on server
This only needs to be done if it is a sync relevant change.
1) Ask aegis or a lobby admin to enforce the new version.
2) Update download page by chaning the version templates on the Wiki.
3) Update the default downloads for each platform on SF.
Installer .exe for Windows, .tar.gz for all other platforms.
Do so through the file(s) properties on this page:${REL_VERS}/
Old stuff, to be cleaned up later
Checklist of stuff that needs to be doing at release time,
not necessarily in the optimal order, but I tried to make it pretty much right.
Spring engine:
Before you start:
- if necessary, increase PATHESTIMATOR_VERSION to force repathing
- make sure changelog is up to date (including version number!)
- talk to people to fix their apps which get included in the installer (Lobby, Downloader...)
Then proceed:
- make sure all packages build correctly (test building on buildbot, test-generate source packages (and check them if they work))
- set buildbot to only produce builds if forced to (comment out schedulers)
- test source package linux (or not if you feel brave)
- test source package windows (ditto)
- bump version number in rts/Game/GameVersion.cpp
- tag the released revision in GIT as e.g. "0.78.0"
- have buildbot compile installer and make source packages
- upload installer to
- upload installer to the big Spring file sites (watch out for notification bots,
it can create chaos if you upload early in release process and the upload gets
widely announced already.)
- upload spring_X.XXbX_src.tar.bz2 to
- upload to
- upload spring_X.XXbX_src.tar.bz2 to Berlios (not too important)
- upload to Berlios (ditto)
- make news post (don't forget to thank contributors, link to installer and source)
- bump version number in rts/Game/GameVersion.cpp to e.g. "0.76b1+" (note the plus)
- enable automatic builds in buildbot again
TASServer (when only spring update):
- update updates.xml with OFFERFILE entries for current Spring version.
- as admin, do "reloadupdateproperties" in TASServer ($Local in TASClient)
- as admin, do "setlatestspringversion 0.76b1" (replace version!)
- as admin, "broadcast" a message that everyone will be kicked due to upgrade
- as admin, kick all users from the server ("killall [reason]")
- set correct Spring version in the shell script that starts server, so it
won't boot people if it ever gets restarted (e.g. power outage)
TASServer (full update, ie. Spring+TASServer):
- easiest is probably to release Spring separately, but usually this is
impossible due to compatibility things.
- update updates.xml with OFFERFILE entries for current lobby version(s)
and current Spring version.
- set correct spring version in the shell script that starts server.
- update sourcecode to latest version
- stop server
- compile server
- do whatever is needed to migrate data, if anything.
- start server
- hotfix the issues that usually arise during TASServer upgrade :-)
- commit the hotfixes
- tag the used server in SVN as e.g. "tags/Lobby/TASServer 0.35"
Jump to Line
Something went wrong with that request. Please try again.