You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently release notes describe a meaningful yet minimal amount of content.
I'd like to see some text explaining to the user which of the many download options to choose.
Also we can debate whether the change log should contain all changes since the last prerelease or the last release. An argument of the list getting too long should be the hint that a new release is due.
Related to this, I'd really like to reduce the number of release types to 2 from 3 if possible. As I previously mentioned, why not make a single debug console enabled Oolite deployment build and get rid of the confusingly named "test" build?
Maybe also get rid of the dev build from the release so there is only one release type per package type (ie. one deployment appimage, one deployment exe, one deployment flatpak). I see little reason to have 3 release types in the actual GitHub release.
As for more frequent releases, I am for this idea provided people are willing to step forward to be testers. I only code. I don't really play Oolite these days so my testing is minimal - load it up and see if I can launch is about it. I don't have time to do more with all the coding I'm doing - so I need people to actually play and tell me if I've broken anything.
@oocube@phkb Do you think the deployment build would need OXP_VERIFIER_ENABLED if it has debug console support and is used by OXP developers?
I'm trying to see whether a single deployment release is feasible. I suspect it is other things besides the debug console and OXP verifier that would impact performance assuming any of the flags has an impact (I've asked on BB, Reddit and Discord if anyone sees a difference between current deployment and test builds).
@oocube@phkb Do you think the deployment build would need OXP_VERIFIER_ENABLED if it has debug console support and is used by OXP developers?
That is beyond my knowledge. I never tried to understand the inner mechanics of the makefiles - just ran them as I was told (and put that into a Github workflow ultimately).
But I can tell that I always run the dev build. It contains the debug console which allows OoliteStarter to act as MQTT bridge. And that again allows Oolite users to create additional IO devices (buttons, displays, ...).
From my point of view neither the test nor the deployment builds are necessary. Maybe they were when runtime performance was an issue, but hardware has evolved over the project's lifetime....
@oocube@phkb Do you think the deployment build would need OXP_VERIFIER_ENABLED if it has debug console support and is used by OXP developers?
That is beyond my knowledge. I never tried to understand the inner mechanics of the makefiles - just ran them as I was told (and put that into a Github workflow ultimately). But I can tell that I always run the dev build. It contains the debug console which allows OoliteStarter to act as MQTT bridge. And that again allows Oolite users to create additional IO devices (buttons, displays, ...).
From my point of view neither the test nor the deployment builds are necessary. Maybe they were when runtime performance was an issue, but hardware has evolved over the project's lifetime....
The feedback I got from a user on Discord was that they don't use the deployment build.
Please remind me: what github workflow(s) use OXP verifier?
Activity
mcarans commentedon Sep 16, 2026
Related to this, I'd really like to reduce the number of release types to 2 from 3 if possible. As I previously mentioned, why not make a single debug console enabled Oolite deployment build and get rid of the confusingly named "test" build?
Maybe also get rid of the dev build from the release so there is only one release type per package type (ie. one deployment appimage, one deployment exe, one deployment flatpak). I see little reason to have 3 release types in the actual GitHub release.
As for more frequent releases, I am for this idea provided people are willing to step forward to be testers. I only code. I don't really play Oolite these days so my testing is minimal - load it up and see if I can launch is about it. I don't have time to do more with all the coding I'm doing - so I need people to actually play and tell me if I've broken anything.
mcarans commentedon Sep 17, 2026
Currently, the deployment build sets these:
For all other builds they are all enabled.
The debug console sits within blocks
#ifndef NDEBUGeg. https://github.com/OoliteProject/oolite/blob/master/src/Core/Debug/OODebugTCPConsoleClient.m#L30. To be included in a deployment release, it needs a separate macro as#ifndef NDEBUGis used for outputting extra logging and probably other debug stuff elsewhere.@oocube @phkb Do you think the deployment build would need OXP_VERIFIER_ENABLED if it has debug console support and is used by OXP developers?
I'm trying to see whether a single deployment release is feasible. I suspect it is other things besides the debug console and OXP verifier that would impact performance assuming any of the flags has an impact (I've asked on BB, Reddit and Discord if anyone sees a difference between current deployment and test builds).
oocube commentedon Sep 18, 2026
That is beyond my knowledge. I never tried to understand the inner mechanics of the makefiles - just ran them as I was told (and put that into a Github workflow ultimately).
But I can tell that I always run the dev build. It contains the debug console which allows OoliteStarter to act as MQTT bridge. And that again allows Oolite users to create additional IO devices (buttons, displays, ...).
From my point of view neither the test nor the deployment builds are necessary. Maybe they were when runtime performance was an issue, but hardware has evolved over the project's lifetime....
mcarans commentedon Sep 19, 2026
The feedback I got from a user on Discord was that they don't use the deployment build.
Please remind me: what github workflow(s) use OXP verifier?
phkb commentedon Sep 19, 2026
I think so. Even if you're doing OXP development, the verifier is a useful tool in tracking down errors.
mcarans commentedon Sep 29, 2026
See #756