Automated build system
This article describes the automated build system that generates the binary releases for the project.
Doomsday's automated build system has been set up for daily builds. Every day at 01:00 UTC, the system checks if the master branch has new commits, and if so, tags and builds a new release. The releases become available for download within a couple of hours from the build time. The system also generates an RSS feed with information about each build. Additionally, the stable branch is checked on the first day of every month, and a new stable build is produced if changes have been made.
How do I use the unstable releases ?
On Windows and macOS, you can either go to the Build Repository page or subscribe to the Build Events RSS feed with your RSS reader. When a new build is available, the feed is updated and you can download the build using the links provided in the post.
On Ubuntu, you can follow the events feed manually like described above. Alternatively, there are prebuilt .deb packages available in skyjake's PPA.
On other operating systems, you need to build the releases from source as the automated build system only provides binaries for Windows, Mac OS X, and Ubuntu. Each build has been tagged in the Git repository; you can check it out and build as you see fit.
All builds created by the system are tagged with a build number whose purpose is to uniquely identify each build. Since these are (at most) daily builds, the build number equals the number of days since January 1, 2011. For instance, the build number for March 7, 2011 is 66. When the Doomsday version number is incremented, the build number will not reset.
An unstable build is one which has been produced automatically by the build system. These builds contain the latest bleeding edge changes, however they are not subject to the same quality assurance and testing process as stable builds.
The unstable builds are 'unstable' in the sense that they are constantly undergoing changes; the latest changes are introduced as soon as they're finished. (Some people like to call this kind of builds "nightly builds".) One can use the unstable releases for normal gameplay, but it is possible that regressions or other bugs end up in the build.
A candidate build is one which has been produced automatically by the build system, after the development process enters the final stages leading up to a stable release.
During a release candidate phase, development effort switches gear from exploratory, new feature implementation to intensified bug fixing and general polishing. There are as many candidate releases as necessary. As development is in "feature freeze" during the candidate phase, it should end as soon as possible; it should not continue for more than a few weeks.
A stable build is one which has been packaged for widespread distribution and has been extensively tested by the development team and volunteers.
A stable release is made after the candidates seem to be of high enough quality. Stable .0 releases occur on a predetermined date. Patch releases (updated stable builds) may be done at any point if there is a need to.
|Builds Repository on dengine.net||Build reports with change logs and build logs, links to files available on SourceForge. You can view details about a particular build at the address dengine.net/build(buildtag), for instance http://dengine.net/build500/.|
|Build Events RSS||RSS feed with build reports and change logs.|
|sjke/doomsday PPA|| Ubuntu 14.04 LTS: |
deb http://ppa.launchpad.net/sjke/doomsday/ubuntu trusty main deb-src http://ppa.launchpad.net/sjke/doomsday/ubuntu trusty main
The automated build system operates on the branch called master, which is Doomsday's primary development branch.
It is crucial that any changes made in the master branch will not break the automated releases. The RSS feed will guarantee that everyone knows the current state of the master, and also who is responsible for any breakage (as the committed revisions are logged).
The main build system scripts are part of the Doomsday Git repository.
distrib/platform_release.py is a script that detects the operating system and runs the appropriate build scripts to generate an installable binary distribution package under distrib/releases.
The script takes no arguments.
distrib/autobuild.py carries out all build operations such as event creation, building, and change log generation.
To see instructions about running the script:
python autobuild.py help
distrib/pilot.py is a cron script that handles task distribution among the autobuilder systems.