From dd6c7a8f2290aba113bee58c2a47d3c636dbb514 Mon Sep 17 00:00:00 2001 From: Francois Miralles <4765639+frmir@users.noreply.github.com> Date: Tue, 14 Apr 2026 13:53:49 -0400 Subject: [PATCH 1/2] Added release cycle files. Signed-off-by: Francois Miralles <4765639+frmir@users.noreply.github.com> --- RELEASE.md | 111 ++++++++++++++++++++++++++++++++++++++ feature-proposal.md | 128 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 239 insertions(+) create mode 100644 feature-proposal.md diff --git a/RELEASE.md b/RELEASE.md index e69de29b..f996fff6 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -0,0 +1,111 @@ +# 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 + +GridFM follows a time‑boxed release cycle. + +- **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` diff --git a/feature-proposal.md b/feature-proposal.md new file mode 100644 index 00000000..ddbcb502 --- /dev/null +++ b/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] " +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. \ No newline at end of file From 2bccc983e0af488fdb4688c9bd8a2c4fd18e0cb0 Mon Sep 17 00:00:00 2001 From: Francois Miralles <4765639+frmir@users.noreply.github.com> Date: Thu, 14 May 2026 16:48:16 -0400 Subject: [PATCH 2/2] Release cadence corrected to *as needed*. Fixing eof for feature-proposal.md. Signed-off-by: Francois Miralles <4765639+frmir@users.noreply.github.com> --- RELEASE.md | 2 -- feature-proposal.md | 2 +- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index f996fff6..55ba8920 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -8,8 +8,6 @@ This process applies to all repositories under https://github.com/gridfm unless ## Release cadence -GridFM follows a time‑boxed release cycle. - - **Patch releases**: as needed for bug fixes - **Minor releases**: as needed for new features - **Major releases**: when backward‑incompatible changes are introduced diff --git a/feature-proposal.md b/feature-proposal.md index ddbcb502..0779348b 100644 --- a/feature-proposal.md +++ b/feature-proposal.md @@ -125,4 +125,4 @@ Who is expected to contribute? ## Additional Notes -Any additional context, open questions, or requests for feedback from maintainers. \ No newline at end of file +Any additional context, open questions, or requests for feedback from maintainers.