You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This document tracks the remaining work before publishing Lumilake's first OSS release. The migration cleanup has already removed the private repository history, dead legacy surfaces, and non-OSS module references. The remaining work is now release hardening rather than source migration.
4
+
5
+
## 1. Documentation and Package Polish
6
+
7
+
Clean up public-facing docs so they describe the current OSS project only.
8
+
9
+
- Update `CONTRIBUTING.md` to remove stale references to `requirements.txt`, `sync_requirements.py`, the `requirements-sync` pre-commit hook, and the `requirements-sync` CI workflow.
10
+
- Update workflow documentation to match the current CI set: lint/typecheck, tests, security, package build, env examples, PR title, and DCO sign-off.
11
+
- Remove the permanent forbidden legacy env-key list from `scripts/dev/check_env_examples.py`; the env example check should validate the current contract without carrying a historical denylist.
12
+
- Add package metadata in `pyproject.toml`: license expression, authors/maintainers, project URLs, keywords, and classifiers.
13
+
- Add concise public reference docs for the surfaces users need after install: environment variables, CLI commands, API overview, architecture, and plugin/hooks model.
14
+
- Ensure README stays as the short quick start and points to the deeper docs instead of duplicating them.
15
+
- Update the issue templates to match the structure of Flowmesh
16
+
17
+
## 2. E2E Release Check
18
+
19
+
Run the project through a real user flow on the self-hosted environment and fix any issues found.
20
+
21
+
- Start from a clean checkout and install with the documented commands.
22
+
- Run `lumilake deploy init` and inspect the generated `.env`.
23
+
- Fill the required local test values and run `lumilake deploy up`.
24
+
- Verify server health and API docs are reachable.
25
+
- Submit at least one representative workflow through the CLI or SDK.
26
+
- Watch the job to completion and verify result retrieval.
27
+
- Confirm runtime artifacts and intermediate outputs go to `S3_ARCHIVE_PREFIX` or lumid.data, not container-local storage.
28
+
- Tear the deployment down with the documented command and confirm no unexpected local state is left behind.
29
+
30
+
The e2e check should be recorded as a release checklist item, not committed as a secret-bearing test. If a reusable script is added, it must accept all credentials and endpoints from the environment and avoid embedding local paths or private data.
31
+
32
+
## 3. Release Machinery
33
+
34
+
Add the workflows and docs needed to publish repeatably.
35
+
36
+
- Add a release documentation page covering version bump, lock refresh, tag policy, TestPyPI validation, PyPI publishing, and rollback/yank guidance.
37
+
- Add release metadata validation, including tag-to-version consistency.
38
+
- Add a GitHub release workflow using pinned actions and trusted publishing where possible.
39
+
- Decide whether the first release publishes only the `lumilake` package or also any split helper packages.
40
+
- Run the package build workflow before tagging and verify the built wheel/sdist import cleanly in a fresh environment.
0 commit comments