...
- 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?