Add stubbed version of new Integrity Bounds/Flags [OTA-134]

[fpezzinosn]

Description

@swift-nav/devinfra

Reserves the IDs associated with the Satellite Bounds messages that are defined in the staging branch.

API compatibility

Does this change introduce a API compatibility risk?

No

API compatibility plan

If the above is "Yes", please detail the compatibility (or migration) plan:

JIRA Reference

https://swift-nav.atlassian.net/browse/OTA-134

[fpezzinosn]

@silverjam Is this what you were referring as stubbing in your staging proposal?

[silverjam]

Yes, this is exactly what I meant

[fpezzinosn]

Will convert this into a draft until all the other messages are merged into staging.

[silverjam]

We need a couple things before we can merge:

• an indication in the version when we're on a staging branch (something a -staging should be appended e.g. v4.2.0-g<git_short_hash>-staging).
• a compiler macro in sbp.h that indicates if we're on a staging branch e.g. #define SBP_STAGING 1

We can implement here and merge master into staging or implement in master, then cherry pick to staging.

These facilities will be used when we cut a release of Starling and disable parsing of the new messages.

[woodfell]

Should these deprecated symbols be _DEP_A? Seems to be a common pattern in other deprecated messages

[fpezzinosn]

I though we used first _DEP and when that one is already used, we switched to _DEP_A.

[woodfell]

What's the plan for all these stubs? Are they going to be included in a release and then redefined later on? Or are they going to be defined properly on this PR before merging?

[fpezzinosn]

It's part of a new proposal.
https://swift-nav.atlassian.net/wiki/spaces/~jason/pages/2198831192/Proposal+for+SBP+message+staging
In the staging branch the full definition of the message is going to be defined. While in master this stubbed version reserve the ids. Once the messages are mature enough and don't need to have any fields updated, they will be promoted from staging to master.

[fpezzinosn]

We need a couple things before we can merge:

• an indication in the version when we're on a staging branch (something a -staging should be appended e.g. v4.2.0-g<git_short_hash>-staging).
• a compiler macro in sbp.h that indicates if we're on a staging branch e.g. #define SBP_STAGING 1

We can implement here and merge master into staging or implement in master, then cherry pick to staging.

These facilities will be used when we cut a release of Starling and disable parsing of the new messages.

@silverjam Is this the correct place to append -staging so that it propagates everywhere?

libsbp/generator/sbpg/generator.py

Lines 87 to 101 in e88fbd8

	def parse_release_version(release: str) -> ReleaseVersion:
	major, minor, patch = release.split('.')[:3]
	major = major.lstrip('v')
	if '-' in patch:
	patch = patch.split('-')[0]
	patch_pre = '{}-alpha'.format(int(patch.split('-')[0]) + 1)
	full_version = "{}.{}.{}".format(major, minor, patch_pre)
	else:
	patch_pre = patch
	full_version = "{}.{}.{}".format(major, minor, patch)
	return ReleaseVersion(major=major,
	minor=minor,
	patch=patch,
	patch_pre=patch_pre,
	full_version=full_version)

[silverjam]

We need a couple things before we can merge:

• an indication in the version when we're on a staging branch (something a -staging should be appended e.g. v4.2.0-g<git_short_hash>-staging).
• a compiler macro in sbp.h that indicates if we're on a staging branch e.g. #define SBP_STAGING 1

We can implement here and merge master into staging or implement in master, then cherry pick to staging.
These facilities will be used when we cut a release of Starling and disable parsing of the new messages.

@silverjam Is this the correct place to append -staging so that it propagates everywhere?

libsbp/generator/sbpg/generator.py

Lines 87 to 101 in e88fbd8

	def parse_release_version(release: str) -> ReleaseVersion:
	major, minor, patch = release.split('.')[:3]
	major = major.lstrip('v')
	if '-' in patch:
	patch = patch.split('-')[0]
	patch_pre = '{}-alpha'.format(int(patch.split('-')[0]) + 1)
	full_version = "{}.{}.{}".format(major, minor, patch_pre)
	else:
	patch_pre = patch
	full_version = "{}.{}.{}".format(major, minor, patch)
	return ReleaseVersion(major=major,
	minor=minor,
	patch=patch,
	patch_pre=patch_pre,
	full_version=full_version)

Yes, this looks correct

[fpezzinosn]

Not the sure if it is the best approach to append a flag conditionally.

[silverjam]

Seems fine, this makes the behavior more explicit

[silverjam]

As an alternative I could see moving this behavior inside the generator an implicitly deciding if we're in a "staging" mode based on some environmental condition, but again, passing the switch makes the behavior more explicit

[silverjam]

When merging please rebase and squash into two commits (make sure to select "rebase and merge" when merging the PR, we want two physical commits to go to the master branch):

• message stubs
• support for "SBP_STAGING"

We'll then do a merge commit of master into staging and revert the "message stubs" commit.

[silverjam]

@fpezzinosn should be able to rebase and merge this PR now