remove loglevel enum [CPP-884]

[adrian-kong]

just a small hack related to LogLevel#error being generated to conflict Self::Error,
since we hotfixed this in the #917 by using text instead of enums (think that takes more bytes), this enum is no longer needed.

[swiftnav-travis]

Frontend and Release Workflow Started here

[pcrumley]

Are these sorts of changes save to take? Is it true that this enum is in no other struct fields, and we can guarantee we will never see it (from a 3rd party or from a persisted capnp) If it was protobuf I believe the correct way to handle this is to make it as deprecated and not remove anything.

[adrian-kong]

Hmmm I'm pretty sure they aren't being used anywhere as I swapped them to strings 🤔 it was one of the reasons that I wanted to get rid of this since it made it much more confusing as to what is being used or not / debugging

BUT yea, some of the capnp changes would break previous capnp recordings which is really bad - wonder how often old capnp recordings are used tho

[pcrumley]

Given that, I would prefer someone else were to review this PR. Int the future based on what i have seen of capnp best practices, they recommend changing the name from foo to obsoleteFoo with a type of AnyPointer if the field is deprecated.

[silverjam]

Given that, I would prefer someone else were to review this PR. Int the future based on what i have seen of capnp best practices, they recommend changing the name from foo to obsoleteFoo with a type of AnyPointer if the field is deprecated.

I think we maybe start doing this, but only if we are going to persist capnp recordings like console_backend/tests/data/console-capnp-20220419-033358.pickle and use them in our CI/CD -- in the past we've treated capnp as ephemeral and in process only.

So I think options are:

• Start maintaining backwards compat with capnp definitions
• Delete console_backend/tests/data/console-capnp-20220419-033358.pickle and make it clear in the docs that capnp is not intended to work between different revisions the app (and why we are doing this, i.e. "because we don't want the burden of maintaining it").

[silverjam]

BUT yea, some of the capnp changes would break previous capnp recordings which is really bad - wonder how often old capnp recordings are used tho

Searching through the code for "pickle" and "capnp" I see we only have one pickle file that's saved in the repo, but it's only used here

swift-toolbox/utils/loop_generate_core.sh

Line 25 in 8acb46a

python -m swiftnav_console.main --read-capnp-recording console_backend/tests/data/console-capnp-20220419-033358.pickle

This isn't used in CI, so it's probably safe to delete console_backend/tests/data/console-capnp-20220419-033358.pickle and just change utils/loop_generate_core.sh to take a pickle file that's passed on the command line.

[pcrumley]

I see, my bet is the breaking change related to loglevel that would have invalidated old capnp was the previous change that switched the log levels for strings.

I thought end users could also save recordings, and it isn't just important if it is in CI/CD?

[adrian-kong]

I thought since it's exposing internal message passing - we shouldn't support backwards compatibility between versions since that would make it very hard to change the internal structures for only debugging purposes - though that would mean you can't debug which version broke (but now thinking it wouldn't be easy to debug on different versions anyways).

[pcrumley]

I had some suggestions for language clarity in the readme but other than that i think it is gtg

[swiftnav-travis]

Frontend and Release Workflow Started here