What feature or improvement would you like to see?
Proposed Architecture
The codebase will be reorganized to isolate the native platforms and the Godot editor project into a clean workspace:
godot-admob-plugin/
├── .github/workflows/ # Consolidated CI/CD for all platforms
├── scripts/ # Global build and export scripts
├── platforms/ # Unified source code directory
│ ├── android/ # Native Android Plugin (Gradle/Kotlin/Java)
│ ├── ios/ # Native iOS Plugin (Xcode/Objective-C++/SCons)
│ └── godot_editor/ # The GDScript Editor Plugin (Godot Project environment)
Release Distribution (Multi-Version Matrix)
Because Godot's GDExtension ABI (iOS) and Android Plugin API can change between minor/patch versions, it is not safe to distribute a single binary compiled against the latest version to all users.
Therefore, the CI will continue to build native binaries for multiple Godot versions.
The difference is that now, instead of creating releases across three different repositories, the CI will upload all platform/version ZIP combinations (e.g., poing-godot-admob-android-v4.3.0.zip, poing-godot-admob-ios-v4.6.1.zip) as assets to a single GitHub Release on the monorepo. This is a very safe and standard practice.
Goals & Benefits
- Single Source of Truth: One PR can now contain GDScript, Kotlin/Java, and Objective-C++ changes simultaneously.
- Lower Barrier to Entry: Contributors only need to fork one repository instead of three.
- Unified CI/CD: One GitHub Actions pipeline to run builds for all platforms.
- Simplified Releases: All generated native binaries will be centralized in the main plugin's releases page.
Tasks
Is your feature request related to a problem? If so, please describe.
Currently, the Godot AdMob Plugin relies on Git submodules to manage the native Android and iOS implementations (godot-admob-android and godot-admob-ios). This architecture creates significant friction for contributors, who must fork and manage three separate repositories to make a single feature change. It also complicates version management and CI/CD pipelines.
To improve the developer experience and simplify maintenance, we need to migrate the existing submodules into a single monorepo.
Additional context
No response
What feature or improvement would you like to see?
Proposed Architecture
The codebase will be reorganized to isolate the native platforms and the Godot editor project into a clean workspace:
Release Distribution (Multi-Version Matrix)
Because Godot's GDExtension ABI (iOS) and Android Plugin API can change between minor/patch versions, it is not safe to distribute a single binary compiled against the latest version to all users.
Therefore, the CI will continue to build native binaries for multiple Godot versions.
The difference is that now, instead of creating releases across three different repositories, the CI will upload all platform/version ZIP combinations (e.g.,
poing-godot-admob-android-v4.3.0.zip,poing-godot-admob-ios-v4.6.1.zip) as assets to a single GitHub Release on the monorepo. This is a very safe and standard practice.Goals & Benefits
Tasks
platforms/androidandplatforms/ios. (Note: Usinggit subtree addis recommended here so we keep the old commit history from the archived repos).project.godotinto the newplatforms/godot_editor/directory..github/workflows/directory. The matrix build generating multiple ZIPs per Godot version will remain intact but all ZIPs will be uploaded to the same release tag.BASE_URLinandroid_handler.gdandios_handler.gdto point to the new monorepo's release page instead of the deprecated repos.README.md, etc.) to point to the new monorepo workflow.godot-admob-android,godot-admob-ios, andgodot-admob-versionsrepositories (mark as read-only).Is your feature request related to a problem? If so, please describe.
Currently, the Godot AdMob Plugin relies on Git submodules to manage the native Android and iOS implementations (
godot-admob-androidandgodot-admob-ios). This architecture creates significant friction for contributors, who must fork and manage three separate repositories to make a single feature change. It also complicates version management and CI/CD pipelines.To improve the developer experience and simplify maintenance, we need to migrate the existing submodules into a single monorepo.
Additional context
No response