Version 1.1.0 Development Tracking

[ZZ-Cat]

I decided to create an issue for you all to see my priority list with development of Version 1.1.0, for the sake of transparency.
There is a milestone for Version 1.1.0, and you can keep up with my development schedule. However, this issue serves as a quick-glance central point-of-interest for you all to see where I am currently at with everything.

The list

The list here is based on my Development Schedule, where you can see what I am working on, and what's receiving my priority attention. All items, unless stated otherwise, appear in their respective categories on a first-in-first-out basis, and progress is made on each one in descending order.
As each item is completed, it is moved to the "Completed" category at the bottom of this list.

In progress

This is what is actively being worked on.
Items in this category are in order of priority, where the topmost item is my highest priority and the lowermost item is my lowest priority.

• Security updates
  • Fix CodeQL errors - This seems to have fixed itself, for some reason.
  • feat(quality control): ✨ Add MISRA C-2012 compliance #138
    • What is MISRA?
    • Website
  • Implement Compile Hardening as outlined by the OpenSSF's Security Guidelines
  • Add a security policy
  • Enable private vulnerability reporting

On hold

An item in this list means that development on it has temporarily stopped, while I focus on higher priorities.

• feat(library): Serial Transmitter Interface #103
• CRSF frame parsing timeout repeatedly expires thus dropping all frames #108
• feat(targets): ✨ Add Raspberry Pi Pico W #113

To-do

This is my "to-do" list, and it contains items that are waiting for me to triage.

• Read CRSF Telemetry Mirrored to Radio Aux Ports #119
• Docs guidance on how to wiring up a receiver. #125
• Issue with 'Add Zip Library' step #139

Planned

This is what I have rattling around in my mind, and need to get it out of the æther, and written here before my short-term memory loss gets the better of me. Keep in mind that anything added here may not make it into the upcoming release, and if it doesn't, it may appear in a follow-up release.

• Update Contribution Guidelines
  • State all commits MUST be verified
  • Pull Request guidelines
  • Condense all guidelines into a concise format, with a list of "key takeaways"
• Add Pull Request Template
• Add PlatformIO requirements to Issue Templates
• New API function: pulseIn()
  This could empower developers to integrate CRSF for Arduino into existing projects with minimal (if any) changes to their existing code-base.

Completed

This is the stuff what's been completed and will make it into the upcoming Version 1.1.0 release.

• fix(compatibility table): 🚑 Add missing STM32F405RG string to deviceNames[] array #107
• ci(CodeQL): Add vulnerability scanning using CodeQL #89
• refactor(quality control): Use an isolated version of CFA_Config.hpp for Defect Detector environment. #117
• chore(library): Clean up deprecated CI and fix defects #116
• refactor(CI): ♻️ Replace existing CIs with one Quality Control CI #115
• refactor(targets): ♻️ Use Arduino-Pico instead of the "official" PlatformIO package for RP2040 #112
• Re-license CRSF for Arduino under the latest GNU Affero General Public License #128
• feat(serial receiver interface): ✨ Introduce three new callbacks #134

Stalled

When development on one (or more) items has stalled for more than a month from its last commit, it is listed here.

Additional

During this time, I ask that you please be patient and understand that I am but one person working on CRSF for Arduino.
I have had my fair share of contributors as time has marched on, and they are not without my respect. I am very grateful for their efforts, and my contributors have been a huge help in lightening the load for me.

However, 99% of the time I am the only one working on CRSF for Arduino, and as its popularity grows, I need to prioritise my focus in order to preserve my work-life balance, negate burning myself out and to negate myself from being overwhelmed with a perceived "MUST do ALL the things... AT ONCE!!!!1111!!!11!"

If you are able, I encourage you to get involved with my project in the following ways:

• Testing the code base on supported hardware;
• Bug-testing and submitting feedback;
• Pull Requests;

Note

For Pull Requests, you MUST have either GPG or SSH signing enabled before your first commit to your Pull Request's branch. All commits in your Pull Request MUST have the green verified badge next to them.
This is the same reason why you write your signature on an official document - It verifies that it's you that wrote the commit and not someone trying to impersonate you.

[BadPotato1007]

So do you have an approximate of when this functionality will be ready? I am planning to use this lib to make a fully diy handset from scratch that can use elrs external modules...

[ZZ-Cat]

So do you have an approximate of when this functionality will be ready?

As my dad used to say: "It will be ready when it's ready." =^/.~=
Or, as Trappy of Team BlackSheep would occasionally joke: "Two weeks."

For real, though. I don't do the whole "deadline" thing.
I'd rather get this done right the first time, as opposed to rushing to meet unrealistic deadlines.

It's unrealistic to ask for a specific "due by" date, when the very nature of software development is unpredictable at best and has its fair share of delays and setbacks at worst.

Another thing ya gotta remember is... I'm just a gal what does this in her free time.
I'm not funded by some big corporation or employed to do this "full-time". I write this stuff on my own terms.