docs: add v0.6 "full event read" milestone before v1.0
All checks were successful
CI / ci (push) Successful in 12m21s

Plan to surface every readable CalendarContract field (reminders, status,
availability, attendee role + self-status, timezone, URL, access level) in
the detail view before write support. Recurrence-override badges and
CATEGORIES/ATTACH stay out (the former folds into v2, the latter is a
provider limitation). Noted only — implementation comes later.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
2026-06-10 23:35:02 +02:00
parent 2cb8b59fb7
commit e78da3d7c1
2 changed files with 33 additions and 7 deletions

View File

@@ -9,14 +9,36 @@
| v0.3 | Month + Week + Day views, view switcher | complete | | v0.3 | Month + Week + Day views, view switcher | complete |
| v0.4 | Event Detail (S4) + humanized recurrence | complete | | v0.4 | Event Detail (S4) + humanized recurrence | complete |
| v0.5 | Calendar filter (M3) + Settings (M4) | complete | | v0.5 | Calendar filter (M3) + Settings (M4) | complete |
| v0.6 | Full event read — surface every readable field | pending |
| v1.0 | Polish pass, F-Droid release | pending | | v1.0 | Polish pass, F-Droid release | pending |
Delivery ran ahead of the original table: Day view (S3) shipped in v0.3 and Delivery ran ahead of the original table: Day view (S3) shipped in v0.3 and
Event Detail (S4) in v0.4, so the Filter/Settings milestone became v0.5. Event Detail (S4) in v0.4, so the Filter/Settings milestone became v0.5.
Jump-to-date (the date-picker half of M2) was **cut from scope** and will not Jump-to-date (the date-picker half of M2) was **cut from scope** and will not
ship. The "Today" half of M2 already shipped in v0.5 (drawer entry). V1 is ship. The "Today" half of M2 already shipped in v0.5 (drawer entry).
therefore feature-complete; only a polish/QA pass remains.
## v0.6 — Full event read
Round out the read-only model so a detail view shows everything the system
actually stores, before write support starts. Scope = `CalendarContract`
columns we don't yet read/display:
- **Reminders** (`VALARM`) — read `CalendarContract.Reminders`, list lead times
- **Status** — Confirmed / Tentative / Cancelled (cancelled shown struck-through)
- **Availability** (`TRANSP`) — Free / Busy chip
- **Attendee extras** — role (required / optional / organizer) + the user's own
`SELF_ATTENDEE_STATUS`
- **Timezone** (`EVENT_TIMEZONE`) — shown only when it differs from the device zone
- **URL** — tappable link card
- **Access level / class** (private / confidential) — small chip (optional, trivial)
Deliberately out of v0.6:
- Recurrence exception / modified-occurrence badges — `Instances` already
resolves correct per-occurrence times for display; this only matters for
editing, so it folds into v2
- `CATEGORIES`, `ATTACH` — not reliably exposed by `CalendarContract`
(provider limitation, not our choice)
## v1.0 — First Public Release ## v1.0 — First Public Release

View File

@@ -5,9 +5,9 @@
## Status ## Status
**Milestone:** v0.5 — Calendar filter (M3) + Settings (M4) (complete) **Milestone:** v0.5 — Calendar filter (M3) + Settings (M4) (complete)
**Phase:** All V1 screens and cross-cutting wiring done. Jump-to-date (the **Phase:** All V1 screens done. Jump-to-date (date-picker half of M2) cut from
date-picker half of M2) was cut from scope; V1 is feature-complete and only a scope. Next up is v0.6 — full event read (surface every readable
polish/QA pass remains before v1.0 `CalendarContract` field) — then a polish/QA pass before v1.0
## Progress ## Progress
@@ -26,5 +26,9 @@ polish/QA pass remains before v1.0
## Next ## Next
1. UI polish / QA pass across all views before v1.0 1. v0.6 — full event read: reminders, status, availability, attendee role +
2. F-Droid release of v1.0 self-status, timezone (when it differs), URL, access level. Read the
`CalendarContract` columns we don't yet pull and show them in the detail
view. (Planned, not started — implement another day.)
2. UI polish / QA pass across all views before v1.0
3. F-Droid release of v1.0