Skip to content

Commit a5e6449

Browse files
frmirfrmir
authored
Merge pull request #64 from gridfm/fmiralles-release-cycle
Add release cycle files.
2 parents e2d9299 + f08a20f commit a5e6449

2 files changed

Lines changed: 237 additions & 0 deletions

File tree

‎RELEASE.md‎

Lines changed: 109 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,109 @@
1+
# GridFM Release Process
2+
3+
This document describes how GridFM releases are planned, coordinated, and delivered.
4+
Its goal is to help contributors from multiple organizations align on *what goes into a release* and *when*.
5+
6+
This process applies to all repositories under https://github.com/gridfm unless stated otherwise.
7+
``
8+
9+
## Release cadence
10+
11+
- **Patch releases**: as needed for bug fixes
12+
- **Minor releases**: as needed for new features
13+
- **Major releases**: when backward‑incompatible changes are introduced
14+
``
15+
16+
## Versioning
17+
18+
GridFM follows semantic versioning:
19+
20+
- **MAJOR**: backward‑incompatible changes
21+
- **MINOR**: new features, backward‑compatible
22+
- **PATCH**: bug fixes and documentation updates
23+
``
24+
25+
## Feature proposal process
26+
27+
To be considered for an upcoming release, contributors must announce their intent
28+
*before* or *early during* the release cycle.
29+
30+
### Step 1 — Open a Feature Proposal
31+
32+
Contributors open a GitHub Issue using the **Feature Proposal** template, including:
33+
34+
- Short description of the feature
35+
- Target repository/repositories
36+
- Expected impact (API change, new model, tooling, docs, etc.)
37+
- Maturity level (experimental / production‑ready)
38+
- Dependencies on other features or data
39+
- Target release (e.g., v0.4)
40+
41+
### Step 2 — Release planning
42+
43+
All feature proposals targeting the release will be collected and the development team will:
44+
45+
- Label them (e.g., `release:v0.4`, `experimental`)
46+
- Identify conflicts or dependencies
47+
- Facilitate discussion (async) if trade‑offs are needed
48+
49+
Acceptance into the release plan does NOT guarantee inclusion.
50+
Features must still meet quality and integration criteria as well as stay in coherence with the GridFM roadmap.
51+
``
52+
53+
## Development and pull requests
54+
55+
All code contributions follow the standard CONTRIBUTING.md process.
56+
57+
Pull requests targeting a specific release should:
58+
59+
- Reference an accepted Feature Proposal issue
60+
- Be labeled with the target release (e.g., `release:v0.4`)
61+
- Include tests, documentation, and examples where applicable
62+
63+
64+
## Release freeze
65+
66+
At the **Release Freeze Date**:
67+
68+
- No new features are accepted
69+
- Only bug fixes, documentation, and release‑blocking changes are allowed
70+
71+
Features not ready by the freeze will be deferred to the next release.
72+
``
73+
74+
## Release candidates
75+
76+
One or more release candidates (RCs) may be published:
77+
78+
- RCs are used for integration testing and validation
79+
- Contributors are expected to test RCs against their use cases
80+
- Blocking issues must be reported with the `release-blocker` label
81+
82+
## Final release
83+
84+
Once all blocking issues are resolved:
85+
86+
- The release is tagged
87+
- Release notes are published
88+
- Artifacts and documentation are updated
89+
90+
The release notes summarize:
91+
- New features
92+
- Breaking changes
93+
- Experimental features
94+
- Known limitations
95+
96+
## Post‑release
97+
98+
After the release:
99+
100+
- A retrospective issue may be opened
101+
- Deferred features are re‑labeled for the next release
102+
- Patch releases may be scheduled if needed
103+
104+
## Common labels:
105+
- `feature-proposal`
106+
- `release:vX.Y`
107+
- `release-blocker`
108+
- `experimental`
109+
- `breaking-change`

‎feature-proposal.md‎

Lines changed: 128 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,128 @@
1+
---
2+
name: 🚀 Feature Proposal
3+
about: Propose a new feature for inclusion in a future GridFM release
4+
title: "[Feature Proposal] <short descriptive title>"
5+
labels: ["feature-proposal"]
6+
assignees: ""
7+
---
8+
9+
## Summary
10+
11+
Provide a concise description of the proposed feature.
12+
What problem does it solve, and why is it useful for GridFM users or contributors?
13+
14+
---
15+
16+
## Motivation and Context
17+
18+
Explain the motivation behind this proposal.
19+
20+
- What use case(s) does this address?
21+
- Is this driven by research, operational needs, or integration with external tools?
22+
- Are there existing issues, discussions, or prototypes related to this?
23+
24+
Link any relevant background material.
25+
26+
---
27+
28+
## Proposed Scope
29+
30+
Describe what is **in scope** and **out of scope** for this feature.
31+
32+
- Core functionality:
33+
- Optional extensions:
34+
- Explicitly excluded items:
35+
36+
This helps align expectations for the release.
37+
38+
---
39+
40+
## Target Release
41+
42+
Which release are you targeting?
43+
44+
- [ ] Next minor release (e.g., v0.X)
45+
- [ ] Future release (not the next one)
46+
- [ ] Unsure / exploratory
47+
48+
If known, specify:
49+
50+
Target version: v0.X
51+
52+
> 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.
53+
54+
---
55+
56+
## Affected Components / Repositories
57+
58+
Which parts of GridFM will be impacted?
59+
60+
- [ ] Models / architectures
61+
- [ ] Data pipelines
62+
- [ ] Training / evaluation code
63+
- [ ] Documentation
64+
- [ ] Tooling / CI
65+
- [ ] Other (please specify)
66+
67+
---
68+
69+
## Maturity Level
70+
71+
How mature is this feature today?
72+
73+
- [ ] Idea / design discussion
74+
- [ ] Research prototype
75+
- [ ] Partially implemented
76+
- [ ] Production‑ready
77+
78+
If a prototype exists, please link to code, papers, or branches.
79+
80+
---
81+
82+
## Dependencies and Risks
83+
84+
Describe any dependencies or risks:
85+
86+
- Dependencies on other features or PRs
87+
- External libraries or datasets
88+
- Backward compatibility concerns
89+
- Performance or scalability considerations
90+
91+
---
92+
93+
## Breaking Changes
94+
95+
Does this feature introduce breaking changes?
96+
97+
- [ ] No
98+
- [ ] Yes (please describe)
99+
100+
If yes, explain:
101+
- What will break?
102+
- Is a migration path planned?
103+
104+
---
105+
106+
## Testing and Validation Plan
107+
108+
How do you plan to validate this feature?
109+
110+
- Unit / integration tests
111+
- Benchmarks
112+
- Reproducibility checks
113+
- Real‑world use cases
114+
115+
---
116+
117+
## Contribution Plan
118+
119+
Who is expected to contribute?
120+
121+
- Primary contributor(s):
122+
- Organization(s):
123+
124+
---
125+
126+
## Additional Notes
127+
128+
Any additional context, open questions, or requests for feedback from maintainers.

0 commit comments

Comments
 (0)