Nomenclature and Betas
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the categories: Engine, Releases.</i>
Let us discuss Doomsday's version numbering and naming (referring to <a href="http://dengine.net/dew/index.php?title=User_talk:Yagisan">Yagisan's comments</a>).
It is true that the 1.9.0 betas 1-5 aren't really "beta" versions of anything. They are much more like alpha versions, considering the goals set for 1.9.0. In our case, "Beta" has the meaning "Work in Progress".
I don't think that changing the naming scheme at this point would be very beneficial to anyone. Version 1.9.0 was intended to contain more profound changes from the very beginning — however, around last December we decided to further extend 1.9.0 to contain changes that would make it possible to provide a more stable API and ABI for 3rd parties. It is supposed to be the defining characteristic of the 1.9 series: that it is possible to create 3rd party plugins that will work with future releases of the 1.9 series, without recompilation of the plugin binary. Furthermore, the API compatibility would guarantee that the plugins would also compile with future 1.9 releases with at most cosmetic changes. It is unfortunate that that 1.9.0 development has been hindered by Real Life obligations, and that releases have been few and far between. But we should remain consistent to our current scheme: we should use the "Beta N" names until we can be reasonably certain that the engine-plugin API is looking clean enough. After that we can release 1.9.0 and start incrementing the third number each release.
Things that need to be done before we can get rid of the Beta names:
<ul>
<li>Unified single player / networked games (i.e., single player games are considered remote as well) — very desirable, should be among the first things for Beta 6.
<li>Review the engine API for potential compatibility problems: assumptions that may become invalid; and what kind of restrictions does the API set on plugin development.
<li>Demo recording and playback issues (made easier by the unified single/multigaming).
<li>Engine-managed savegames (relates to the unified single/multigaming).
<li>Better precaching (might require changes to engine API?) / texture content adaptation (reduce quality when necessary).
</ul>
Note: Bias lighting is engine-internal and can be postponed to the actual 1.9.x feature releases.
Let us discuss Doomsday's version numbering and naming (referring to <a href="http://dengine.net/dew/index.php?title=User_talk:Yagisan">Yagisan's comments</a>).
It is true that the 1.9.0 betas 1-5 aren't really "beta" versions of anything. They are much more like alpha versions, considering the goals set for 1.9.0. In our case, "Beta" has the meaning "Work in Progress".
I don't think that changing the naming scheme at this point would be very beneficial to anyone. Version 1.9.0 was intended to contain more profound changes from the very beginning — however, around last December we decided to further extend 1.9.0 to contain changes that would make it possible to provide a more stable API and ABI for 3rd parties. It is supposed to be the defining characteristic of the 1.9 series: that it is possible to create 3rd party plugins that will work with future releases of the 1.9 series, without recompilation of the plugin binary. Furthermore, the API compatibility would guarantee that the plugins would also compile with future 1.9 releases with at most cosmetic changes. It is unfortunate that that 1.9.0 development has been hindered by Real Life obligations, and that releases have been few and far between. But we should remain consistent to our current scheme: we should use the "Beta N" names until we can be reasonably certain that the engine-plugin API is looking clean enough. After that we can release 1.9.0 and start incrementing the third number each release.
Things that need to be done before we can get rid of the Beta names:
<ul>
<li>Unified single player / networked games (i.e., single player games are considered remote as well) — very desirable, should be among the first things for Beta 6.
<li>Review the engine API for potential compatibility problems: assumptions that may become invalid; and what kind of restrictions does the API set on plugin development.
<li>Demo recording and playback issues (made easier by the unified single/multigaming).
<li>Engine-managed savegames (relates to the unified single/multigaming).
<li>Better precaching (might require changes to engine API?) / texture content adaptation (reduce quality when necessary).
</ul>
Note: Bias lighting is engine-internal and can be postponed to the actual 1.9.x feature releases.
Comments
Personally, I think we should run as many betas as needed to do what we want to do before release, even if it leads to 10 or more releases.
Previously, the engine/plugin interface hasn't been very clearly defined. Much of the map data has been in shared usage. This is something that 1.9 is targeting to change. If we define a set of functions and data types and commit to not changing them in the future, we can have API and even ABI compatibility.
Naturally we cannot guarantee that the binary interface produced by one compiler is the same as the one produced by another, but in the Windows and OS X worlds the situation seems quite manageable: we choose a compiler and stick with it.
What is your opinion on proprietary plugins - ie those mods that people won't release the source for. I think we should explicitly ban those types of plugins.
What we can do is make more stringent version number checks, and then possibly refuse to load a plugin if it assumes an obsolete version of Doomsday is in use.
Not being able to play a plugin on an engine I help develop would antagonise me immensely, and demoralise me.