...
Milestone | Planned deadline | Actual deadline | Description of the Milestone | Comments |
---|---|---|---|---|
M0 | date as initially planned | date as really committed |
| problems, decisions, reasons for the delay, etc |
M1 |
| |||
M2 |
| |||
M3 |
| |||
M4 |
| |||
RC0 |
| |||
Deployment | official deployment executed |
Planned scope
Project | Scope | Dependencies | |
---|---|---|---|
Project Name (link) | Overall description of the project's increment in the particular release |
Jira | |
server | Tungsten Fabric | ||
serverId | 82691efe-91a0-3cff-8e71-932ce5d4700b | key | DOC-31|
Requirements
- Releases MUST have a web/wiki page that explains exactly what is in the release
- The page SHOULD be automatically generated if at all possible
- Releases MUST be in the form of docker images stored in DockerHub
- Releases MUST be architected as microservices and be Kubernetes compatible
- Releases MUST have a regular cadence
- Ideally releases WOULD happen every month
- The minimum cadence velocity MUST be 3 months, not 6 months
- Releases MUST have some form of labels, tags, or branching scheme that allows for mapping included features and bug fixes into a CHANGELOG and RELEASE NOTES
- See #1 above
- The scheme MUST be documented here in the Wiki
- There MUST be a variety of release types for various purposes to be determined; a starting point might be:
- Experimental releases for nightly or high interval testing looking for build breakages
- Lightly tested builds
- Stable regular builds for doing downstream integration testing into commercial distributions
- Standard testing
- Production builds that can be used for official releases
- Extensive scalability and performance testing (as possible)
- Experimental releases for nightly or high interval testing looking for build breakages
- SHOULD develop a scheme for LTS builds based on production builds (above)
- QUESTION: what does an LTS build mean for an open source project that has no official support?