makiolaj/calendula
1
0
Fork 1
Code Actions Releases 32 Activity

docs: retire the last planning file, fold its constraints into PROJECT.md

Browse Source 
REQUIREMENTS.md was the same pre-tracker genre as the roadmap and state
snapshot, and had drifted into being wrong rather than merely stale: it
listed the home-screen widget and full-text search under "Out of Scope
(V3+)" when both have shipped.

Its one still-useful part was the Constraints list, so that moves into
PROJECT.md as a section of its own — platform, offline-first, privacy, i18n,
tests/CI, reproducible builds, licence. The tech-stack pins it carried were
already duplicated in PROJECT.md's Stack, which is also where the drift came
from: two files restating the same versions, only one getting updated.

While there: AGP was recorded as 9.1.1, actually 9.2.1, and the Stack
section described no submodule despite floret-kit being a
compiled-from-source composite build.

.planning/ is now just PROJECT.md, which describes the project rather than
its plan.
This commit is contained in:
Jean-Luc Makiola
2026-07-30 10:36:55 +02:00
parent 0dfbc75844
commit caa4d65a47
3 changed files with 24 additions and 59 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
docs/README.md
View File

@@ -10,15 +10,16 @@ Where to look for what:
| [`RELEASING.md`](RELEASING.md) | Release process: versioning, the merge-driven pipeline, the two-forge split, secrets, key custody |
| [`../CHANGELOG.md`](../CHANGELOG.md) | Release history (Keep a Changelog, SemVer) |
| [Issues](https://codeberg.org/jlmakiola/calendula/issues) + [milestones](https://codeberg.org/jlmakiola/calendula/milestones) | **The roadmap.** What's planned, in progress, and shipped — a milestone maps to its `release/vX.Y.Z` branch |
| [`../.planning/PROJECT.md`](../.planning/PROJECT.md) | What the project is, stack, naming, infrastructure |
| [`../.planning/REQUIREMENTS.md`](../.planning/REQUIREMENTS.md) | Historical V1/V2 requirement checklist, plus the stack/platform constraints |
| [`../.planning/PROJECT.md`](../.planning/PROJECT.md) | What the project is: core value, stack + version pins, constraints, naming, forge/release infrastructure |
| [`design/`](design/) | Per-feature design notes kept for features whose provider behaviour is worth recording |
| [`../fastlane/metadata/android/`](../fastlane/metadata/android/) | Store metadata (single source of truth): descriptions, title, icon, screenshots (DE + EN). Harvested directly by the official F-Droid repo; transformed into the self-hosted repo layout at release time by [`../scripts/fastlane_to_fdroid_localized.sh`](../scripts/fastlane_to_fdroid_localized.sh) |
| [`../fdroid-metadata/`](../fdroid-metadata/) | App-level F-Droid control file (`*.yml`: Categories, License, links) for the self-hosted repo's `fdroid update` |
| [`fdroid-official/`](fdroid-official/) | Recipe + notes for publishing to the **official** F-Droid repo (reproducible build + developer-signed binary) |
Conventions: planning lives in the **issue tracker**, not in this repository. The
`.planning/` files that predated it (a roadmap and a development-state snapshot)
are gone — issues and milestones say the same thing without going stale.
`.planning/` files that predated it (a roadmap, a development-state snapshot, and
a per-milestone requirement checklist) are gone — issues and milestones say the
same thing without going stale. `PROJECT.md` is what remains, and it describes
the project rather than its plan.
`ARCHITECTURE.md` is the authoritative orientation tour: it is updated with the
code, and is the right place for a lesson learned about the calendar provider.