Skip to content

Conversation

@ES-Alexander
Copy link
Contributor

@ES-Alexander ES-Alexander commented Dec 21, 2025

Closes #12 + closes #13 by replacement, rebasing over main and factoring in relevant feedback (plus a couple of other fixes determined while testing). Includes initial output generations for both, plus a general generation back to the latest generation date (which updates Sub-4.5).

@patrickelectric reviewing is likely easiest by commit rather than by final file state(s).

@ES-Alexander ES-Alexander force-pushed the add-missing-firmware-types branch 6 times, most recently from d816eb7 to 708dd0a Compare December 22, 2025 02:09
@ES-Alexander ES-Alexander changed the title Add missing firmware types Add missing firmware types and dev versions Dec 22, 2025
@ES-Alexander
Copy link
Contributor Author

ES-Alexander commented Dec 22, 2025

If we're including development versions, should we stop bothering to process the beta versions? There should always be a corresponding minor that's either stable or dev, unless there's a beta released during a skipped minor (e.g. if ArduSub-4.5 is stable, and ArduSub-4.7 is dev, there could be a unique beta in ArduSub-4.6, although it seems unlikely).

Alternatively, maybe it makes sense to keep betas in a non-versioned folder (e.g. just ArduSub-beta)? With the current sorting, if the minor is the same then the stable will override the beta. I'm not sure what the preferred behaviour is there - stables are fully released (so seem extra worth representing), but betas are sometimes newer 🤷‍♂️

If need be I can update the sort order to properly handle considerations like ArduSub 4.5.0 < ArduSub-beta (on 4.5.1) < ArduSub-4.5.1, but it's fiddly, and then we don't have consistency over which information we lose (e.g. a folder can switch multiple times between representing beta and stable data depending on releases, instead of always being either dev if a new minor, or stable if an existing stable minor).

Copy link
Member

@patrickelectric patrickelectric left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • The last commit (708dd0a) says Blimp but it changes AP_Peripherals.
  • 580b8f7 has as title: "scripts: run_parsers: include development versions" but it's creating a tag in the repository.
  • The first commit is doing multiple changes at once, can you brean in multiple commits ?
    • It's adding Tracker, Blimp, AP_Periph
    • It's change the logic of get_version_for_tag
    • It's adding staticmethod
    • Moving Groundskeeper to self

@ES-Alexander ES-Alexander force-pushed the add-missing-firmware-types branch 5 times, most recently from 5b409fe to d9d792c Compare January 2, 2026 08:40
@ES-Alexander
Copy link
Contributor Author

  • The last commit (708dd0a) says Blimp but it changes AP_Peripherals.

I've updated the commit message to better reflect what it does.
I also re-ran that generation, because ardupilot has had some updates since then.

580b8f7 has as title: "scripts: run_parsers: include development versions" but it's creating a tag in the repository.

It's creating a temporary local tag so that the latest changes get included in the normal tag handling. I've added some code commentary to better describe what it's doing.

  • The first commit is doing multiple changes at once, can you brean in multiple commits ?

Done.


I also added an improvement to how the initial patch handling gets printed, and did a back-fill generation for 4.6 because there were apparently some changes to the parameters since our last generation of it.

Copy link
Member

@patrickelectric patrickelectric left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason for generating the files in this PR over having the CI generating it ?

@ES-Alexander
Copy link
Contributor Author

I suppose the “latest” ones could be done by CI - I just generated them to make sure it was working properly.

The back-fill ones are necessary because Groundskeeper assumes generations are complete up to the date of the latest repo commit (even if it’s actually a code change), so any tags from before that commit won’t get automatically generated/updated metadata. We’ve already had some code commits merged in this repo since the last ArduPilot tags, so they now require manual generation.

@ES-Alexander ES-Alexander force-pushed the add-missing-firmware-types branch from d9d792c to cae6f17 Compare January 2, 2026 15:22
@ES-Alexander
Copy link
Contributor Author

I removed the non-required "latest" generations (since CI should do them), and moved the old back-fill one to just after the code cleanup commits :-)

Makes it easier to follow, and see which patch will be processed for a given minor release.
@ES-Alexander ES-Alexander force-pushed the add-missing-firmware-types branch from cae6f17 to 9608d08 Compare January 2, 2026 15:45
@ES-Alexander
Copy link
Contributor Author

Improved some commit message explanations, and fixed a slightly incorrect code comment.

ES-Alexander and others added 3 commits January 2, 2026 23:57
Required because repo merged code changes between the last metadata generation occurring and the relevant ArduPilot tags being made, so the current tags are being ignored by Groundskeeper.
Required because the tags are older than the latest repo commit, so Groundskeeper will ignore them.
Treats the latest ArduPilot code state as a temporary new version, so we have metadata generated for the master branch (if it is configured as a newer major or minor than the existing releases).

Co-authored-by: ES-Alexander <[email protected]>
@ES-Alexander ES-Alexander force-pushed the add-missing-firmware-types branch from 9608d08 to 13e2927 Compare January 2, 2026 15:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants