Jean-Luc Makiola
7f58f81fe1
Port Calendula's current CI/release pipeline: - ci.yaml: pull_request-triggered, change-scope classification (docs/metadata-only PRs skip the Android build but still report a green CI), and a reproducible-release invariant guard. - release.yaml: the committed versionName is the source of truth — a bump reaching main triggers the release, which builds, signs, publishes to the F-Droid repo, then mints the vX.Y.Z tag + Gitea release and mirrors it to Codeberg with the signed APK + SHA-256 checksum. workflow_dispatch runs the re-sign-only recovery path. - Gitea releases are flagged as pre-releases while MAJOR is 0. - build.gradle.kts: reproducible-release invariants (vcsInfo, dependenciesInfo) + a releaseTest variant for the on-device gate. - fastlane/ becomes the single source of truth for store metadata; the localized F-Droid layout is generated from it at release time. - Port scripts/, .gitea/ISSUE_TEMPLATE/, and rewrite docs/RELEASING.md for the versionName-in-main model; fix stale references elsewhere. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Agendula — documentation
Agendula is a Material 3 Expressive task app for Android: a pure front-end over
the OpenTasks TaskContract provider (synced by DAVx5 / SmoothSync / DecSync
over CalDAV), with no own database or sync stack. Sibling to
Calendula. See the
top-level ../README.md for the project pitch.
Index
| Doc | What it covers |
|---|---|
ARCHITECTURE.md |
How Agendula is built today — layers, the data seam, provider resolution, the reminder engine, DI, build/tooling, manifest. Start here to work on the code. |
ROADMAP.md |
Status and what's next — milestones (M0–M6 + Posture B), what's done, open decisions, how to build/verify. |
PLAN.md |
The original implementation plan and design rationale — the A-now-B-later thesis, what transfers from Calendula, the locked decisions. The "why". |
RELEASING.md |
How to cut a release — the git-tag-as-source-of-truth flow, CI jobs, F-Droid repo, required secrets. |
Also: ../CHANGELOG.md (Keep a Changelog format; tag sections
feed the release notes).
How the docs relate
- PLAN is the design decisions (mostly stable; the "why").
- ARCHITECTURE is the current shape of the code (kept in sync with the source as it grows).
- ROADMAP is the moving status layer (update as milestones land).
- RELEASING is the operational runbook.