wraggster
March 2nd, 2011, 10:36
News via http://www.aep-emu.de/ (http://www.aep-emu.de/)
A new version of the Doom, Heretic and Hexen source port Doomsday Engine (http://www.aep-emu.de/Web_Links-req-visit-lid-54.html) has been released. They also created a new build system, which will be generating new releases on a regular basis. More information after the break.
You can find some shareware versions of Doom and other ID games at Q-Marines DOOM WADs Dat (http://www.q-marine.de/wad-dat/) project page.
Quote:
Last week I had some time off from work due to illness and decided to spend the time productively: we now have a system that is building a binary release automatically on the three major platforms: Windows, Mac OS X, and Ubuntu (http://www.vmware.com/vmtn/vm/ubuntu.html).
Gravity
Let us consider for a moment the significance of this development. As Doomsday (http://www.aep-emu.de/Web_Links-req-visit-lid-54.html) is a hobby project, it is only natural that team members stray out from the source trunk into developing interesting and fancy new things. However, this does not help at all with producing actual releases that people at large might want to use. In essence, the situation is missing gravity: the far-flung development branches need a constant pull to become part of the official release stream. Hand-made releases lack gravity because it is cumbersome to make them and no one wants to do that on a regular basis. Hence, no releases for months on end. Also, important bug fixes are left stranded on some development branch with a bunch of half-finished changes with no way to get them released quickly. But with an automated build system churning out releases effortlessly (and on a regular schedule), we have the necessary gravity to motivate team members to finalize their work and integrate it back to the trunk (in reasonably-sized chunks) to get it released.
I have decided to make some other important changes as well. The never-ending “Beta” phase is now over and done with. The team’s goal is not to make “Beta” quality releases — each release should be stable and good enough for normal use. The trunk (i.e., master branch) is henceforth intended to be as bug-free and stable as possible. New code will be merged in only after it has been finished with in a development branch. Consequently, the version number of the Doomsday (http://www.aep-emu.de/Web_Links-req-visit-lid-54.html) Engine is upgraded to 1.9.7 (from beta7).
Builds and Numbers
As the build system will be generating new releases on a regular basis, there is a need to identify each build. The builds created by the system are tagged with a build number. Since these are (at most) daily builds, the build number equals the number of days since January 1, 2011. For instance, today’s build number is 59. When we increase the Doomsday (http://www.aep-emu.de/Web_Links-req-visit-lid-54.html) version number, the build number will not reset.
As to the build schedule, for now I have set it up for biweekly (Monday/Friday) builds. Every week, at exactly 12:00 (EET) on Monday and Friday, the system tags and builds a new release. The releases will become available for download within a couple of hours from the build time.
Official Stable Releases
As the automated builds are not intended to be the “final” releases, but rather work-in-progress versions, we will still need to manually mark certain builds as official stable releases. These will be linked to on the project web site. However, in practice, this means that the latest release files are simply uploaded to SourceForge (http://sourceforge.net/) and the build tag is removed from the file names.
Nifty Things
The automated build system has a couple of useful features. First of all, the builds can be tracked using RSS. One can subscribe to the build event feed and be immediately notified of each build via the RSS app of choice (or Google Reader). This is extremely helpful for both the team members and the users. The feed itself provides links to the build files, compiler logs, and the Git changelog of all revisions since the previous build.
Another nice feature is that the build system maintains an apt repository for Ubuntu (http://www.vmware.com/vmtn/vm/ubuntu.html) users. Currently I am able to only build 32-bit binaries. On the plus side, the .deb packages also include Snowberry, so the experience should be on par with the other platforms. As a bonus, the .deb package contains an apt source list file that automatically retrieves updates from the Doomsday (http://www.aep-emu.de/Web_Links-req-visit-lid-54.html) Builds repository. I.e., once the .deb is installed, new builds can be installed simply by running apt-get.
The 64-bit build can be done manually from source.
Source Releases?
For the time being I have decided not to make any source releases. There are two options available if you wish to have access to the source:
For just viewing the source, the SF.net repository source browser is quite helpful.
For full access to all revisions, clone the Git repository on your local computer.
Development Practices
For team members, it is worthwhile to appreciate the importance of the master branch from here on out. It is crucial that any changes made in the master 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). In case a breakage occurs, my first action is to remove the offending revisions from the master, returning it to a known working state.
This also means that no day-to-day development can occur in the master branch, as it must remain releasable at any given moment. Branches must be used for working on new features until they are ready for merging into the master. Trivial bug fixes are an exception: they should be done in the master branch so that they are released immediately. (Team members should take extra care of fixing bugs on the correct branch!)
An important thing to notice is that currently the master is based on the Beta6.9 release. DaniJ has been working on lots of improvements and fixes in the old beta6 branch in the past months, and these are currently not part of the official release stream. I expect that in the coming weeks the most important changes from the beta6 branch will be merged to the master to get them out in the open.
My focus has recently been on the hawthorn branch (i.e., the 2.0 stuff), but due to the new release system I am reconsidering my approach to the 2.0 development. Stay tuned for a post of my thoughts on that a bit later on.
In Closing…
I hope that the changes outlined in this post will bring enhanced vitality to the project. At a minimum there will be a steady stream of fresh binaries for people to play with.
Once more, here’s the build events RSS feed: http://code.iki.fi/builds/events.rss
Happy Doomsdaying,
Jaakko
A new version of the Doom, Heretic and Hexen source port Doomsday Engine (http://www.aep-emu.de/Web_Links-req-visit-lid-54.html) has been released. They also created a new build system, which will be generating new releases on a regular basis. More information after the break.
You can find some shareware versions of Doom and other ID games at Q-Marines DOOM WADs Dat (http://www.q-marine.de/wad-dat/) project page.
Quote:
Last week I had some time off from work due to illness and decided to spend the time productively: we now have a system that is building a binary release automatically on the three major platforms: Windows, Mac OS X, and Ubuntu (http://www.vmware.com/vmtn/vm/ubuntu.html).
Gravity
Let us consider for a moment the significance of this development. As Doomsday (http://www.aep-emu.de/Web_Links-req-visit-lid-54.html) is a hobby project, it is only natural that team members stray out from the source trunk into developing interesting and fancy new things. However, this does not help at all with producing actual releases that people at large might want to use. In essence, the situation is missing gravity: the far-flung development branches need a constant pull to become part of the official release stream. Hand-made releases lack gravity because it is cumbersome to make them and no one wants to do that on a regular basis. Hence, no releases for months on end. Also, important bug fixes are left stranded on some development branch with a bunch of half-finished changes with no way to get them released quickly. But with an automated build system churning out releases effortlessly (and on a regular schedule), we have the necessary gravity to motivate team members to finalize their work and integrate it back to the trunk (in reasonably-sized chunks) to get it released.
I have decided to make some other important changes as well. The never-ending “Beta” phase is now over and done with. The team’s goal is not to make “Beta” quality releases — each release should be stable and good enough for normal use. The trunk (i.e., master branch) is henceforth intended to be as bug-free and stable as possible. New code will be merged in only after it has been finished with in a development branch. Consequently, the version number of the Doomsday (http://www.aep-emu.de/Web_Links-req-visit-lid-54.html) Engine is upgraded to 1.9.7 (from beta7).
Builds and Numbers
As the build system will be generating new releases on a regular basis, there is a need to identify each build. The builds created by the system are tagged with a build number. Since these are (at most) daily builds, the build number equals the number of days since January 1, 2011. For instance, today’s build number is 59. When we increase the Doomsday (http://www.aep-emu.de/Web_Links-req-visit-lid-54.html) version number, the build number will not reset.
As to the build schedule, for now I have set it up for biweekly (Monday/Friday) builds. Every week, at exactly 12:00 (EET) on Monday and Friday, the system tags and builds a new release. The releases will become available for download within a couple of hours from the build time.
Official Stable Releases
As the automated builds are not intended to be the “final” releases, but rather work-in-progress versions, we will still need to manually mark certain builds as official stable releases. These will be linked to on the project web site. However, in practice, this means that the latest release files are simply uploaded to SourceForge (http://sourceforge.net/) and the build tag is removed from the file names.
Nifty Things
The automated build system has a couple of useful features. First of all, the builds can be tracked using RSS. One can subscribe to the build event feed and be immediately notified of each build via the RSS app of choice (or Google Reader). This is extremely helpful for both the team members and the users. The feed itself provides links to the build files, compiler logs, and the Git changelog of all revisions since the previous build.
Another nice feature is that the build system maintains an apt repository for Ubuntu (http://www.vmware.com/vmtn/vm/ubuntu.html) users. Currently I am able to only build 32-bit binaries. On the plus side, the .deb packages also include Snowberry, so the experience should be on par with the other platforms. As a bonus, the .deb package contains an apt source list file that automatically retrieves updates from the Doomsday (http://www.aep-emu.de/Web_Links-req-visit-lid-54.html) Builds repository. I.e., once the .deb is installed, new builds can be installed simply by running apt-get.
The 64-bit build can be done manually from source.
Source Releases?
For the time being I have decided not to make any source releases. There are two options available if you wish to have access to the source:
For just viewing the source, the SF.net repository source browser is quite helpful.
For full access to all revisions, clone the Git repository on your local computer.
Development Practices
For team members, it is worthwhile to appreciate the importance of the master branch from here on out. It is crucial that any changes made in the master 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). In case a breakage occurs, my first action is to remove the offending revisions from the master, returning it to a known working state.
This also means that no day-to-day development can occur in the master branch, as it must remain releasable at any given moment. Branches must be used for working on new features until they are ready for merging into the master. Trivial bug fixes are an exception: they should be done in the master branch so that they are released immediately. (Team members should take extra care of fixing bugs on the correct branch!)
An important thing to notice is that currently the master is based on the Beta6.9 release. DaniJ has been working on lots of improvements and fixes in the old beta6 branch in the past months, and these are currently not part of the official release stream. I expect that in the coming weeks the most important changes from the beta6 branch will be merged to the master to get them out in the open.
My focus has recently been on the hawthorn branch (i.e., the 2.0 stuff), but due to the new release system I am reconsidering my approach to the 2.0 development. Stay tuned for a post of my thoughts on that a bit later on.
In Closing…
I hope that the changes outlined in this post will bring enhanced vitality to the project. At a minimum there will be a steady stream of fresh binaries for people to play with.
Once more, here’s the build events RSS feed: http://code.iki.fi/builds/events.rss
Happy Doomsdaying,
Jaakko