Add release cycle files.

RELEASE.md

@@ -0,0 +1,109 @@
+# GridFM Release Process
+
+This document describes how GridFM releases are planned, coordinated, and delivered.
+Its goal is to help contributors from multiple organizations align on *what goes into a release* and *when*.
+
+This process applies to all repositories under https://github.com/gridfm unless stated otherwise.
+``
+
+## Release cadence
+
+- **Patch releases**: as needed for bug fixes
+- **Minor releases**: as needed for new features
+- **Major releases**: when backward‑incompatible changes are introduced
+``
+
+## Versioning
+
+GridFM follows semantic versioning:
+
+- **MAJOR**: backward‑incompatible changes
+- **MINOR**: new features, backward‑compatible
+- **PATCH**: bug fixes and documentation updates
+``
+
+## Feature proposal process
+
+To be considered for an upcoming release, contributors must announce their intent
+*before* or *early during* the release cycle.
+
+### Step 1 — Open a Feature Proposal
+
+Contributors open a GitHub Issue using the **Feature Proposal** template, including:
+
+- Short description of the feature
+- Target repository/repositories
+- Expected impact (API change, new model, tooling, docs, etc.)
+- Maturity level (experimental / production‑ready)
+- Dependencies on other features or data
+- Target release (e.g., v0.4)
+
+### Step 2 — Release planning
+
+All feature proposals targeting the release will be collected and the development team will:
+
+- Label them (e.g., `release:v0.4`, `experimental`)
+- Identify conflicts or dependencies
+- Facilitate discussion (async) if trade‑offs are needed
+
+Acceptance into the release plan does NOT guarantee inclusion.
+Features must still meet quality and integration criteria as well as stay in coherence with the GridFM roadmap.
+``
+
+## Development and pull requests
+
+All code contributions follow the standard CONTRIBUTING.md process.
+
+Pull requests targeting a specific release should:
+
+- Reference an accepted Feature Proposal issue
+- Be labeled with the target release (e.g., `release:v0.4`)
+- Include tests, documentation, and examples where applicable
+
+
+## Release freeze
+
+At the **Release Freeze Date**:
+
+- No new features are accepted
+- Only bug fixes, documentation, and release‑blocking changes are allowed
+
+Features not ready by the freeze will be deferred to the next release.
+``
+
+## Release candidates
+
+One or more release candidates (RCs) may be published:
+
+- RCs are used for integration testing and validation
+- Contributors are expected to test RCs against their use cases
+- Blocking issues must be reported with the `release-blocker` label
+
+## Final release
+
+Once all blocking issues are resolved:
+
+- The release is tagged
+- Release notes are published
+- Artifacts and documentation are updated
+
+The release notes summarize:
+- New features
+- Breaking changes
+- Experimental features
+- Known limitations
+
+## Post‑release
+
+After the release:
+
+- A retrospective issue may be opened
+- Deferred features are re‑labeled for the next release
+- Patch releases may be scheduled if needed
+
+## Common labels:
+- `feature-proposal`
+- `release:vX.Y`
+- `release-blocker`
+- `experimental`
+- `breaking-change`

feature-proposal.md

@@ -0,0 +1,128 @@
+---
+name: 🚀 Feature Proposal
+about: Propose a new feature for inclusion in a future GridFM release
+title: "[Feature Proposal] <short descriptive title>"
+labels: ["feature-proposal"]
+assignees: ""
+---
+
+## Summary
+
+Provide a concise description of the proposed feature.
+What problem does it solve, and why is it useful for GridFM users or contributors?
+
+---
+
+## Motivation and Context
+
+Explain the motivation behind this proposal.
+
+- What use case(s) does this address?
+- Is this driven by research, operational needs, or integration with external tools?
+- Are there existing issues, discussions, or prototypes related to this?
+
+Link any relevant background material.
+
+---
+
+## Proposed Scope
+
+Describe what is **in scope** and **out of scope** for this feature.
+
+- Core functionality:
+- Optional extensions:
+- Explicitly excluded items:
+
+This helps align expectations for the release.
+
+---
+
+## Target Release
+
+Which release are you targeting?
+
+- [ ] Next minor release (e.g., v0.X)
+- [ ] Future release (not the next one)
+- [ ] Unsure / exploratory
+
+If known, specify:
+
+Target version: v0.X
+
+> Note: Targeting a release does not guarantee inclusion; the feature must meet integration and quality criteria as well as stay in coherence with the GridFM roadmap.
+
+---
+
+## Affected Components / Repositories
+
+Which parts of GridFM will be impacted?
+
+- [ ] Models / architectures
+- [ ] Data pipelines
+- [ ] Training / evaluation code
+- [ ] Documentation
+- [ ] Tooling / CI
+- [ ] Other (please specify)
+
+---
+
+## Maturity Level
+
+How mature is this feature today?
+
+- [ ] Idea / design discussion
+- [ ] Research prototype
+- [ ] Partially implemented
+- [ ] Production‑ready
+
+If a prototype exists, please link to code, papers, or branches.
+
+---
+
+## Dependencies and Risks
+
+Describe any dependencies or risks:
+
+- Dependencies on other features or PRs
+- External libraries or datasets
+- Backward compatibility concerns
+- Performance or scalability considerations
+
+---
+
+## Breaking Changes
+
+Does this feature introduce breaking changes?
+
+- [ ] No
+- [ ] Yes (please describe)
+
+If yes, explain:
+- What will break?
+- Is a migration path planned?
+
+---
+
+## Testing and Validation Plan
+
+How do you plan to validate this feature?
+
+- Unit / integration tests
+- Benchmarks
+- Reproducibility checks
+- Real‑world use cases
+
+---
+
+## Contribution Plan
+
+Who is expected to contribute?
+
+- Primary contributor(s):
+- Organization(s):
+
+---
+
+## Additional Notes
+
+Any additional context, open questions, or requests for feedback from maintainers.