Repository navigation
Improve release notes #743
Description
Activity
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.
Currently, the deployment build sets these:
add_project_arguments( '-DNDEBUG', '-DOO_CHECK_GL_HEAVY=0', '-DOO_OXP_VERIFIER_ENABLED=0', '-DOO_LOCALIZATION_TOOLS=0', '-DDEBUG_GRAPHVIZ=0', '-DOO_FOV_INFLIGHT_CONTROL_ENABLED=0', language: c_family, )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 @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....
Reacted by Mike@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?
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.