Version 2
If you are a long-time Doomsday'er, you may have been looking forward to the big "Version 2.0" for several years. Once upon a time, during the 1.9 betas, we dreamt of rewriting and overhauling the engine's internals completely before going to version 2. However, in reality this was highly impractical due to the size and complexity of the codebase. Instead, in recent years we've been following a model where certain smaller sections of the code are improved, redesigned or perhaps even replaced over time. I don't see this process ever being "complete", because there is always something to improve and some new feature to add.
So, in practice, development happens gradually — each step on its own is a minor one. But when many of these accumulate it does warrant bumping the major version number, or otherwise we'd be at 1.x forever. With this in mind, a good way to use the major version is to indicate particularly significant changes, like the removal of the frontend, or always running in client/server mode, or perhaps even offering a built-in map editor.
Version numbers are interesting because on one hand they are just arbitrary numbers, but on the other they do carry meaning about the magnitude of the changes. One thing is certain, though: future plans and the Roadmap are never set in stone, and changes in circumstances and available developer manpower may warrant changing the plan. The evolution of Doomsday should be considered as a continuum that is guided by the Roadmap where priorities are defined for the big milestones and smaller tasks. Our current development model assigns the following meaning for version numbers (major.minor.patch):
We are now officially moving to version 2.0.0 in the unstable builds (the "master" branch). The major milestone we are achieving with 2.0 is the removal of the Snowberry frontend app. This will have a big impact on how you interact with Doomsday: launching will take you immediately to the Home screen, where you can select which game to start, or pick a savegame to load, and see what multiplayer games are currently ongoing.
Hitherto, Doomsday has always had a frontend app of some kind that has handled part of the responsibility of setting up game sessions and configuring some subset of the engine's features. Removing this frontend has both UX and technical implications. Doomsday will now have to learn how to deal directly with resource packages, and this will allow it to gracefully handle them also when it comes to savegames and multiplayer games.
In version 2.0 we are also applying a number of technical changes that have waiting in the wings. The project's build system changes to CMake, and distribution packages will be generated by CPack. The Doomsday SDK (foundation libraries and headers) will be included in the installers. The OS X version will be distributed as a plain .dmg disk image, with applications on it that you can launch directly. The Windows version will be distributed as an .msi installer package built using WiX. All libraries, executables, tools, and tests are part of the CMake build on all platforms.
The early 2.0 unstable builds will be a bit rough because they lack functionality for configuring game sessions with add-ons, PWADs, model packs, or any other external resources via the GUI. I recommend using 1.15.x until this functionality is added (assuming you want to play with custom resources). It is also always possible to run from the command line and specify the resources manually. The frontend in 1.15 lets you preview the command line options, and you can use the same ones in the 2.0 unstable builds.
So, in practice, development happens gradually — each step on its own is a minor one. But when many of these accumulate it does warrant bumping the major version number, or otherwise we'd be at 1.x forever. With this in mind, a good way to use the major version is to indicate particularly significant changes, like the removal of the frontend, or always running in client/server mode, or perhaps even offering a built-in map editor.
Version numbers are interesting because on one hand they are just arbitrary numbers, but on the other they do carry meaning about the magnitude of the changes. One thing is certain, though: future plans and the Roadmap are never set in stone, and changes in circumstances and available developer manpower may warrant changing the plan. The evolution of Doomsday should be considered as a continuum that is guided by the Roadmap where priorities are defined for the big milestones and smaller tasks. Our current development model assigns the following meaning for version numbers (major.minor.patch):
- Major: Significant roadmap milestone completed.
- Minor: A set of smaller roadmapped changes completed.
- Patch: Bumped whenever a patch release is made.
We are now officially moving to version 2.0.0 in the unstable builds (the "master" branch). The major milestone we are achieving with 2.0 is the removal of the Snowberry frontend app. This will have a big impact on how you interact with Doomsday: launching will take you immediately to the Home screen, where you can select which game to start, or pick a savegame to load, and see what multiplayer games are currently ongoing.
Hitherto, Doomsday has always had a frontend app of some kind that has handled part of the responsibility of setting up game sessions and configuring some subset of the engine's features. Removing this frontend has both UX and technical implications. Doomsday will now have to learn how to deal directly with resource packages, and this will allow it to gracefully handle them also when it comes to savegames and multiplayer games.
In version 2.0 we are also applying a number of technical changes that have waiting in the wings. The project's build system changes to CMake, and distribution packages will be generated by CPack. The Doomsday SDK (foundation libraries and headers) will be included in the installers. The OS X version will be distributed as a plain .dmg disk image, with applications on it that you can launch directly. The Windows version will be distributed as an .msi installer package built using WiX. All libraries, executables, tools, and tests are part of the CMake build on all platforms.
The early 2.0 unstable builds will be a bit rough because they lack functionality for configuring game sessions with add-ons, PWADs, model packs, or any other external resources via the GUI. I recommend using 1.15.x until this functionality is added (assuming you want to play with custom resources). It is also always possible to run from the command line and specify the resources manually. The frontend in 1.15 lets you preview the command line options, and you can use the same ones in the 2.0 unstable builds.
Comments