v4.4.19

Release notes

Changes

• Added Android to RunnerOperatingSystem (TFCPS_RemoteBuild) and changed flutter's appbundle-build (TFCPS_CodeUnitSpecific_Flutter) to delegate unconditionally to an Android-task-runner via run_program_on_remote_runner, analogous to how ios-builds already delegate to a macOS-task-runner. This is the client-side counterpart of the new SCTaskRunnerAndroid-codeunit in the SCBuilder-repository, which replaces the Android-SDK/NDK-toolchain that used to be bundled in the SCBuilder-image itself.
• Updated the remote-build reference-article to document the new Android-runner.
• Added a dedicated IOS value to RunnerOperatingSystem and changed flutter's ios-build to delegate to it instead of the generic MacOS value, so it is served by the new, dedicated SCTaskRunnerIOS-codeunit instead of SCTaskRunnerMacOS (which is currently unused, kept for a future generic macOS-native build-step). Updated the remote-build reference-article accordingly.
• Added a linux-target to TFCPS_CodeUnitSpecific_Flutter.build() (flutter build linux), copying the result to BuildResult_Linux. Unlike windows/macos/ios/appbundle it does not delegate to a permanently-running RunnerOperatingSystem-task-runner; instead it runs the build in a plain, ad-hoc sibling-container of the SCBuilder-image (resolved from .ScriptCollection/OCIImages/ImageDefinition.csv, started and removed just for that one build-step), because that image already has the Linux-desktop-toolchain (clang/cmake/ninja/libgtk-3-dev). Handles both running directly on the host (bind-mount) and running inside a container itself (--volumes-from a sibling-container, same approach TFCPS_VisualRegressionTests already uses).
• Added a macos-target to TFCPS_CodeUnitSpecific_Flutter.build(), analogous to ios: delegates unconditionally to RunnerOperatingSystem.MacOS, served by SCTaskRunnerMacOS (which is used again now, no longer unused). Updated the remote-build reference-article and SCTaskRunnerMacOS's own docs (ReadMe/codeunit.xml/pyproject.toml/docstring) accordingly.
• Added ScriptCollection.TFCPS.Flutter.ArbTranslationsOrganizer, moved out of AthenaTournamentManager (a consuming repository), which keeps a Flutter-codeunit's ARB-translation-files in sync with XLIFF 2.0 files. ArbTranslationsOrganizer.organize_translations(tf, arb_folder_relative_path, languages) is now reusable by any Flutter-codeunit instead of being hardcoded to one repository's package-layout. The module-level _BASE_LANGUAGE-constant of the original code became the class-attribute ArbTranslationsOrganizer.BaseLanguage.
• The former TranslationTools-module (moved together with ArbTranslationsOrganizer in the same change, for the same reason) is now the ARBTranslationHelper-class in the same file (ArbTranslationsOrganizer.py), its former module-level functions became @staticmethod/@classmethods of that class instead of a separate module.
• Added RepositoryHistoryAnalyzer and RepositoryDiagramGenerator (openspec-change add-git-history-diagrams). RepositoryHistoryAnalyzer reads a repository's git history into committer-activity-data (get_committers/get_committer_emails, based on git shortlog -n -s[-e]; get_git_history_data(repository_path, scale) aggregated per day/ISO-week/year via the new GitHistoryScale-enum; get_commits_per_weekday_data/get_commits_per_hour_data aggregated per weekday/hour-of-day). RepositoryDiagramGenerator turns that data into Vega-Lite diagram-specifications (generate_committer_timeline, generate_committer_pie_chart, generate_commits_per_weekday_chart, generate_commits_per_hour_chart), each with a per-data-point tooltip (exact commit-count/percentage) and a legend-hover tooltip showing the hovered committer's email-address. Both classes only produce the Vega-Lite specification (json); rendering it into an image is left to the existing ScriptCollectionCore.generate_chart_diagram.
• Moved ArbTranslationsOrganizer out of TFCPS.Flutter to the top-level ScriptCollection-package and decoupled it from TFCPS_CodeUnitSpecific_Flutter_Functions: organize_translations now takes a ScriptCollectionCore-instance plus already-resolved arb_folder/xlf_folder paths directly, instead of a Flutter-codeunit-object, and returns the xlf-files' translation-state-statistics. TFCPS_CodeUnitSpecific_Flutter_Functions gained its own organize_translations/translate_safe (the latter moved out of the former ARBTranslationHelper.translate_safe), which resolve those paths from Flutter's own codeunit-conventions and write a TranslationState.json.
• Added TranslationState (ScriptCollectionCore: Initial/Translated/Reviewed/Final). sync_xlf2_files (and the internal __sync_xlf2_files) now return, per language, the share of translation-units in each state, and generate_translation_state_diagram turns that into a Vega-Lite stacked-bar-chart specification. TFCPS_CodeUnitSpecific_NodeJS_Functions.organize_translations now writes that diagram-specification too, analogous to Flutter.
• sync_xlf2_files now asserts that a culture-specific language (e.g. de-AT) is only passed if its base-language (de) is also contained in the list, and no longer special-cases a single-language call (which used to skip syncing entirely). Its returned statistics exclude en and culture-specific languages.
• Added write_languages_as_resource (TFCPS_Tools_General), writing a codeunit's sorted translation-language-list to Other/Resources/Languages/Languages.txt; called from both NodeJS's and Flutter's organize_translations.
• Removed the Taskfile-based __translate()-step from the pre-merge build-pipeline (TFCPS_CodeUnit_BuildCodeUnits), since translating is now driven by each codeunit's own organize_translations instead.
• Added generate_full_vega_chart_diagram (full Vega-syntax, rendered via vg2svg) next to the existing Vega-Lite-based generate_chart_diagram (vl2svg) in ScriptCollectionCore, sharing a common __generate_chart_diagram_with_renderer. Added generate_svg_files_from_vega_files_for_repository/generate_svg_files_from_vegalite_files_for_repository (TFCPS_Tools_General), rendering *.vega.json/*.vegalite.json files under a repository's Other/Reference-folder into svg; both are now called from the build-pipeline, analogous to the existing plantuml-rendering.
• TFCPS_CodeUnitSpecific_Flutter_Functions.do_common_tasks now runs flutter clean before building, and its dockerized linux-build now runs flutter pub get && flutter build linux against a dedicated, per-codeunit docker-volume for .dart_tool instead of reusing the bind-mounted host-folder, to avoid a stale incremental-compiler-cache from a host-run breaking the containerized build (reproduced for MetisGameManager).
• Simplified UnassignedVariablesCheck's bare-annotation-detection: a class body's direct bare annotations are now always excluded, regardless of decorators/base-classes, instead of only for @dataclass/TypedDict/NamedTuple/BaseModel/Protocol.
• Added dependency CountryInformation>=1.0.12.
• Added the options add_readme_of_codeunit_to_package, add_license_of_repository_to_package and add_changelog_of_repository_to_package and branch_of_published_state to TFCPS_CodeUnitSpecific_Flutter_Functions.build(). They put the readme of the codeunit (<codeunit>/ReadMe.md), the license of the repository (License.txt) and the changelog of the repository (Other/Resources/Changelog, rendered as one section per version, newest version first) into the copies of the package which the sourcecode-artifacts contain, under the names a package-registry expects (README.md/LICENSE/CHANGELOG.md), and replace every link of that readme which points into the repository by an absolute one. This makes the artifact of a dart-package directly publishable to pub.dev without the codeunit having to implement that step in its own Build.py, and without the package containing a second readme which would drift apart from the one of the codeunit.
• TFCPS_CodeUnitSpecific_Flutter_Functions.linting() now runs flutter analyze instead of doing nothing but normalizing invisible characters, so a linting-issue (or an error) of a flutter-codeunit lets the build fail instead of staying unnoticed. It is run once per package-folder of the codeunit; which folders those are is determined by their pubspec.yaml, so a codeunit which is its own package and one which contains its package in a subfolder are both linted without further configuration. The optional argument package_name states that folder explicitly if the automatic detection is not wanted. A package below such a folder (for example the example-application of a package) is analyzed together with the package it belongs to; the dependencies of every one of those folders are resolved (flutter pub get) before the analysis, because flutter analyze only resolves them by itself when it has to resolve anything at all, so an already-resolved package would leave the package below it unresolved and every symbol of its dependencies would be reported as undefined.
• TFCPS_CodeUnitSpecific_Flutter_Functions.build() now generates the bill-of-materials of the codeunit (Other/Artifacts/BOM/<codeunit>.<version>.bom.xml, CycloneDX 1.6), so a flutter-codeunit does not produce the warning about the missing BOM-artifact anymore. It is generated from the pubspec.lock of the package (which is resolved first if it does not exist yet), because pub has no equivalent of cyclonedx-npm or cyclonedx-gomod which could be demanded from every machine which builds a flutter-codeunit. Every package of the lockfile becomes a component, a package from pub.dev additionally with its package-url, its sha256-hash and a link to its version on the registry.