Naros
commented
1 month ago Regarding cherry-picking and introducing subtle behavior changes, I believe that can be solved by the developer setting their git submodule reference to a specific sha or tag rather than a generalized branch name. This would allow the Godot team to freely cherry-pick as needed to former branches while allowing developer builds to remain unaffected by the cherry-picks.
As for the CHANGELOG, I think every project does this slightly differently depending on the workflow that works best for them. What I can describe is how I do this professionally in the projects I am a committer for.
- The
main/masterbranch has a CHANGELOG that maintains all changes applied to that branch during the development cycle (alpha, beta, cr, and the first x.y.0.stable) releases. - There is a CHANGELOG on each of the minor branches (4.1, 4.2, 4.3) that mirrors the contents of
main/masterup to the point where the x.y branch is created when x.y.0.stable is officially cut. From this point forward, this CHANGELOG will be amended with any cherry-picks to this x.y branch.
The layout of this CHANGELOG is what I think is really the most critical, with a layout like the following:
## Version
**DATE** - **Link to GitHub/Jira list of issues tagged for this release**
### New features
* Feature A
* Feature B
### Breaking Changes
* List of each breaking change and what the impact is
### Fixes
* List of fixesNow, could this CHANGELOG be represented similarly, given the tools that the Godot development team uses between GitHub and its project management? Absolutely.
I think what's most important is not where this CHANGELOG is maintained but rather the distinction between new features and regression fixes and any change that could introduce a breaking change that needs consideration by the developer.
For example, using the Bitfield to unsigned int discussion from the last GDExtension meeting, if there was a note in the CHANGELOG that outlined that PR 1234 introduced a compatibility change that GDExtension authors are responsible for treating bitfields as uint64_t and that negative values shouldn't be used, that gives a solid indication of what the impact of that change would be. As it stands now, it requires not only a review of the commit history but, in some cases, going to the PR to digest the discussion and change to understand the potential impact.
If it's easier, from the Godot team's point of view, to version godot-cpp separately and maintain things in a singular branch, I don't see any problem as a consumer of godot-cpp in theory, but we'd need to see what that workflow really would look like I think.
dsnopek
Bromeon
allenwp
vnen
Describe the project you are working on
GDExtension and godot-cpp.
Describe the problem or limitation you are having in your project
Right now, we have 3 active branches of godot-cpp:
4.14.2master(for 4.3, but soon it'll be for 4.4, and we'll add a new4.3branch)We try to cherry-pick as much as we can from godot-cpp
masterto all earlier branches as far back as4.1(we don't cherry-pick to4.0and make as few changes there as we can, since it's incompatible with Godot 4.1+).We intend to keep doing this, because GDExtensions targeting a particular Godot version (starting with Godot 4.1) will work for that version and any later version. This creates an incentive for GDExtension developers to target the earliest possible version, in order to give the widest compatibility.
However, this cherry-picking creates a couple problems:
masterto4.1and4.2took me about 90 minutes. However, as more versions are released, this could grow if we continue to cherry-pick all the way back to4.1. However, we could work around this by only supporting the 2 previous minor versions, or something like that, in order to keep this constant.4.1branch over the long-term for compatibility reasons, we want to bring these bug fixes to them. However, since the changes to the godot-cpp4.1branch don't get a version number (except when a Godot release happens), we don't have a good way to provide a CHANGELOG. Even if we attempted to list the changes with the Godot synchronized release, it's a little awkward in that we're making the same godot-cpp changes to4.1,4.2, etc at the same time, but we don't have any way to connect them to each other, since godot-cpp is versioned as Godot is.The first problem isn't that big of a deal, however, the second one is increasingly creating headaches for developers.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
I propose that we support all Godot 4.1+ versions using a single branch of godot-cpp, and then version godot-cpp independently of Godot itself.
We could still include the latest
extension_api.jsonfiles for each minor version of Godot, but developers would indicate to the buildsystem which Godot version they wished to be compatible with (rather than selecting a particular branch of godot-cpp), which would select which one to use. (And they can still point to a customextension_api.json, of course.)We could always keep the latest
gdextension_interface.hin the repo, but we'd use#ifdefs (based on the version pulled from theextension_api.json) to use the correct functions for the correct Godot compatibility.And this would allow us to make a CHANGELOG for each released version of godot-cpp, which lists all the changes and how they affect developers, regardless of what Godot version they are targeting for their extension.
I'm not sure what the version number for this "universal" godot-cpp should start on, perhaps 4.4.0? That way versions 4.3 and below still refer to the old way, and we reserve version 5.0 to potentially mean something different for Godot 5.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Described in the previous section :-)
If this enhancement will not be used often, can it be worked around with a few lines of script?
n/a
Is there a reason why this should be core and not an add-on in the asset library?
n/a