Status: public project status and maintenance policy
Scope: maintenance modes, freeze conditions, and archive/transfer expectations
Audience: contributors, adopters, and maintainers who need to understand what happens if project velocity changes
Open-source users need more than a feature list.
They also need to know:
- whether the project is actively moving
- what “maintenance mode” would mean here
- how the project would communicate a slowdown, freeze, transfer, or archive
This file exists to make those expectations explicit.
CogLang is currently in:
active experimental maintenance
That means:
- the project is still evolving
- the maintainers are still willing to tighten contracts and improve public documentation
- readers should treat stability claims as coming from release and contract docs, not from feature velocity alone
This is the current mode.
Typical work includes:
- spec/runtime/conformance alignment
- CLI and documentation improvements
- host contract tightening
- carefully chosen additions that fit the language boundary
This mode does not imply rapid feature growth.
If the project moves into maintenance mode, the default expectation becomes:
- bug fixes
- documentation clarifications
- compatibility-preserving contract work
- conformance corrections
What usually stops in this mode:
- large language-surface expansion
- new subsystems without strong maintainer support
- roadmap items that require sustained implementation bandwidth
If the project moves into compatibility freeze, the expectation becomes:
- published surfaces remain available as reference material
- only minimal compatibility or correctness fixes are likely
- roadmap work is effectively paused
This mode is intended to preserve trust for existing readers and integrators, even if active evolution has stopped.
If the project can no longer be actively maintained, maintainers should prefer one of two explicit outcomes:
- transfer to new maintainers
- archive with the status made explicit
Silent abandonment is the least desirable outcome.
The following do not automatically force a transition, but they are examples of conditions that may trigger a public reassessment:
- sustained lack of maintainer capacity
- sustained absence of meaningful community use or contribution
- a decision that the remaining roadmap no longer justifies active language evolution
- emergence of a broadly adopted alternative that serves the same practical role well enough that
CogLangno longer has a distinct maintenance case
If such a reassessment happens, the project should say so plainly rather than leaving contributors to guess.
If project status changes materially, maintainers should update:
README.mdROADMAP.mdMAINTENANCE.md- the latest release note or status note
The important thing is not to promise constant velocity.
The important thing is to make status changes legible.
If the project is in active experimental maintenance:
- contributions that tighten contracts, tests, docs, and host boundaries are usually the safest fit
If the project is in maintenance mode:
- contributions should assume a more conservative acceptance bar
If the project is in compatibility freeze:
- contributors should expect very limited scope unless maintainers explicitly reopen a line of work
Use these documents together:
CogLang_Release_Notes_v1_1_0.md: what is currently promisedROADMAP.md: what the project is trying to move towardMAINTENANCE.md: how project status may change if velocity or maintainer capacity changes
CogLang aims to be explicit not only about what it is building, but also about how it would slow down, freeze, transfer, or archive if active development can no longer be sustained.