asf-tooling commented on issue #914:
URL:
https://github.com/apache/tooling-trusted-releases/issues/914#issuecomment-4410045242
<!-- gofannon-issue-triage-bot v2 -->
**Automated triage** — analyzed at `main@2da7807a`
**Type:** `new_feature` • **Classification:** `no_action` •
**Confidence:** `high` • ⚠️ **Stale — consider closing**
**Application domain(s):** `shared_infrastructure`, `release_lifecycle`
### Summary
Issue #914 requests a lifecycle event data model with specific fields
(project_key, cycle_key, version_key, event type, datetime, reference URLs) and
search indexes. This feature has already been fully implemented: the database
migration (0076), the LifecycleEventType enum, the LifecycleEvent model, the
ECMA-428 CLE document generator (atr/cle.py), and comprehensive unit tests
(tests/unit/test_cle.py) all exist in the codebase. The prior discussion
between @ppkarwasz, @sbp, and @dave2wave about 'end of support' vs 'end of
maintenance' terminology was resolved in favor of 'eos' (end of support) per
ECMA-428 § 7.3, and this is reflected in the implementation.
### Where this lives in the code today
#### `atr/models/sql.py` — `LifecycleEventType` (lines 262-268)
_currently does this_
The enum defines all six event types specified in the issue (release,
archive, withdraw, eod, eos, eol).
```python
class LifecycleEventType(enum.StrEnum):
RELEASE = "release"
ARCHIVE = "archive"
WITHDRAW = "withdraw"
EOD = "eod"
EOS = "eos"
EOL = "eol"
```
#### `migrations/versions/0076_2026.05.06_e5fa9b30.py` — `upgrade` (lines
39-54)
_currently does this_
The migration creates the lifecycleevent table with all fields specified in
the issue plus foreign keys and the three search indexes (project_event,
cycle_event, version_event).
```python
def upgrade() -> None:
op.create_table(
"lifecycleevent",
sa.Column("id", sa.Integer(), nullable=False),
sa.Column("project_key", sa.String(), nullable=False),
sa.Column("cycle_key", sa.String(), nullable=True),
sa.Column("version_key", sa.String(), nullable=True),
sa.Column(
"event",
sa.Enum("RELEASE", "ARCHIVE", "WITHDRAW", "EOD", "EOS", "EOL",
name="lifecycleeventtype"),
nullable=False,
),
sa.Column("effective", sql.UTCDateTime(timezone=True),
nullable=False),
sa.Column("published", sql.UTCDateTime(timezone=True),
nullable=False),
sa.Column("target_event_id", sa.Integer(), nullable=True),
sa.Column("reference_urls", sa.JSON(), nullable=False),
```
#### `atr/cle.py` — `project_document` (lines 62-75)
_currently does this_
The CLE document generator reads from LifecycleEvent rows and renders to
ECMA-428 wire format, demonstrating the model is fully in use.
```python
def project_document(
project: sql.Project,
events: Iterable[sql.LifecycleEvent],
releases: Iterable[sql.Release],
*,
now: datetime.datetime,
) -> dict[str, Any]:
"""Generate a CLE document covering every event for a project.
This is the canonical form per ECMA-428: one document per component.
`releases` are needed to resolve version strings and cycle release sets
at render time.
"""
return _document(project, list(events), list(releases), now=now)
```
#### `tests/unit/test_cle.py` —
`test_render_event_release_emits_version_and_separate_dates` (lines 58-73)
_currently does this_
Comprehensive test coverage exists for the CLE rendering of lifecycle events.
```python
def test_render_event_release_emits_version_and_separate_dates():
project = SimpleNamespace(key="foo",
version_method=sql.VersionMethod.SIMPLE)
rel = SimpleNamespace(version="1.2.3", key="foo-1.2.3",
cycle_key="foo-default")
event = _event(
event=sql.LifecycleEventType.RELEASE,
effective=datetime.datetime(2026, 1, 1, tzinfo=datetime.UTC),
published=datetime.datetime(2025, 12, 1, tzinfo=datetime.UTC),
version_key="foo-1.2.3",
cycle_key="foo-default",
)
rendered = cle._render_event(project, event, {"foo-1.2.3": rel},
{"foo-default": [rel]})
assert rendered["type"] == "released"
assert rendered["effective"] == "2026-01-01T00:00:00Z"
assert rendered["published"] == "2025-12-01T00:00:00Z"
assert rendered["version"] == "1.2.3"
assert rendered["license"] == "Apache-2.0"
```
### Proposed approach
The lifecycle event model described in this issue has been fully
implemented. The database schema (migration 0076), the LifecycleEventType enum
in atr/models/sql.py, the ECMA-428 CLE document generator in atr/cle.py, and
unit tests in tests/unit/test_cle.py all exist and match the requirements
specified in the issue. The discussion about 'end of support' terminology was
resolved by @sbp citing the ECMA-428 § 7.3 narrow definition, and @dave2wave
concurred by changing eom to eos. This is reflected in the implementation. No
further code changes are needed; the issue can be closed as completed.
### Open questions
- The LifecycleEvent SQLModel class definition is likely in the truncated
portion of atr/models/sql.py - cannot verify its exact field definitions match
the migration.
- Whether a lifecycle_event() query builder method exists in
atr/db/__init__.py (file was truncated) for the three search patterns described
in the issue.
- Whether storage writers or API endpoints exist for creating lifecycle
events (not visible in provided files).
### Staleness assessment
_opened 50 days ago; last human comment 3 days ago._
Last human activity was 3 days ago (2026-05-05). The implementation
(migration dated 2026-05-06) was created after the last discussion comment. The
issue is actively being worked on and appears to have been completed very
recently.
**Recommendation: consider closing this issue.** If the maintainer agrees,
the agent's assessment above provides the rationale to include in a closing
comment.
_The agent reviewed this issue and is not proposing patches in this run.
Review the existing-code citations and open questions above before deciding
next steps._
### Files examined
- `atr/cle.py`
- `migrations/versions/0076_2026.05.06_e5fa9b30.py`
- `atr/models/sql.py`
- `tests/unit/test_cle.py`
- `atr/db/__init__.py`
- `atr/db/interaction.py`
- `atr/storage/__init__.py`
- `atr/storage/writers/release.py`
### Related issues
This issue appears related to: #912.
_Both define project cycle and lifecycle event models for tracking release
information_
---
*Draft from a triage agent. A human reviewer should validate before merging
any change. The agent did not run tests or verify diffs apply.*
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]