Nomenclature and Betas

edited 2006 Dec 29 in Developers
<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.

Comments

  • I'm all for maintaining an API, but not an ABI. It's not feasible. Different compliers, operating systems and even system running modes change the ABI.

    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.
  • This is the engine/plugins interface we are talking about. It is quite a simple C API. I don't really think it's that difficult to make sure that once a plugin has been compiled for one version of 1.9, it will run on future versions as well. The API can even be extended without breaking binary compatibility.

    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.
  • If only it where that simple. Service releases have been known to slightly change the way compilers build making an ABI difficult to maintain. I am working on making the Windows release build with MinGW as I don't like depending on a particular version of MSVC to build deng on that platform.

    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.
  • I don't think we should ban closed-source plugins. If the author of a plugin is willing to accept that his plugin will potentially only work for a short period of time without constant maintenance, then that's fine by me. In fact, 1.9 is supposed to make the life of this kind of plugin authors easier, thanks to the aim towards improved backwards compatibility for future releases.

    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.
  • As someone that isn't on a platform supported by many closed source vendors, I feel great concern over permitting those practices that lead to plugins not working on my system.

    Not being able to play a plugin on an engine I help develop would antagonise me immensely, and demoralise me.
Sign In or Register to comment.