Skip to content

ROADMAP.md

Latest commit

 

History

History
89 lines (77 loc) · 5.72 KB

ROADMAP.md

File metadata and controls

89 lines (77 loc) · 5.72 KB
Raw

Public roadmap

PyBLE is developed in public. This roadmap communicates direction rather than promising dates; accepted work is tracked through GitHub issues and milestones.

The detailed firmware v0.6.1 and v0.7.0 proposal records the post-v0.6.0 contract-hardening and Reliable Projects candidates. The v0.6.1 hardening implementation has been published on owner confirmation; v0.7.0 remains non-normative and requires separate maintainer approval.

Available now

  • iPad external beta through TestFlight
  • Android PyBLE 0.2.0 published for Google Play open testing, subject to Play's account, country, device, and testing availability
  • PBLE/1 editing, run/stop, console, and file workflows over BLE
  • Offline Blockly with beginner GPIO and NeoPixel examples
  • The published firmware v0.6.1 covers five exact profiles: four ESP Web Serial installers and the verified Pico 2 W UF2/manual-BOOTSEL path. Publication follows the owner's qualification confirmation, recorded in the owner confirmation. Incomplete automated evidence is preserved unchanged; the qualified v0.6.0 release remains a separate historical baseline. The original qualification tracker #24 was closed as superseded on 2026-09-13; its incomplete checklist is not marked completed.
  • Guided tutorials with reviewed Lenovo captures, the firmware functional reference, and the separate official example collection
  • MIT-licensed app, agent firmware, protocol, website, tests, and release tools

Near term

  • Complete the C1-S1 remaining evidence: confirmed pilot ownership/setup, actual capacity and five real baseline observations. Existing Play 0.2.0 (8) and TestFlight 0.2.0 (6) installations and launches are verified on connected tablets; fresh enrollment/reinstallation was not exercised. The pilot kit, recovery design and validation inventory are prepared; this does not complete the Sprint or board qualification.
  • Deliver the engineering-accepted bounded current-text recovery candidate. Candidate 0.3.0+9 passes its contract and declared app-only matrix with exact test conditions recorded. Full A-24 and Blocks graph persistence remain separate scope. The original 45–72 hour estimate remains a forecast, not measured effort.
  • Maintain the corrected public TestFlight description: English (U.S.) copy was saved/reloaded and independently verified publicly on 31 October.
  • Complete channel delivery for qualified app 0.3.0+9. PR #41 merged after all 36 checks on its final head passed. Internal-account TestFlight 0.3.0 (9) offer/Open, installed identity and bounded smoke are verified (delivery record); the update transaction was not observed. External build 9 is submitted and Waiting for Review; Google Play open-testing build 9 is submitted with Changes in review; approval/delivery remain pending. Lenovo still has Play 0.2.0 (8); earlier iPad build-6 evidence remains historical. The Android publication review records live open-testing availability. The prepared build-8 handoff remains a source-specific historical record. The current Android installation check matches 38 retained code/asset entries to that AAB; this supports its historical source mapping, not complete binary equivalence or validation of subsequent source changes. The iPad check records TestFlight build 6 with source mapping unresolved; distribution-owner review is needed for conflicting minimum-OS metadata before making a support claim.
  • Review the proposed v0.7.0 Reliable Projects scope before implementation.
  • Expand user-facing setup, recovery, and board-specific wiring guidance
  • Gather Android open-testing feedback and improve installation and recovery guidance
  • Convert remaining pre-public planning references into focused GitHub issues
  • Improve automated app-to-board integration coverage

Toward 1.0

  • Stabilize public app and firmware release processes
  • Publish a reusable PBLE/1 conformance kit for new board ports
  • Define the maintainer process and evidence template for non-ESP32 ports
  • Complete accessibility, localization, privacy, and security review
  • Establish compatibility and deprecation guarantees for PBLE/1

Future ports

PyBLE is not limited to ESP32. A proposed port should demonstrate:

  1. supported MicroPython execution;
  2. BLE GATT peripheral capability;
  3. a maintained PBLE/1 agent integration;
  4. sufficient flash, RAM, and runtime isolation;
  5. build and protocol-conformance results;
  6. transfer recovery and filesystem-safety behavior; and
  7. repeatable HIL evidence on an exact board profile.

Open an issue before substantial porting work so the compatibility contract and validation plan can be agreed first.