In general for a release we want to:
- Describe the features in the release to the community (prior to cutting release)
- Trial run: In Dev Standup with Greg
- Forum: Community hangout (trial run in Dev Standup)
- Review documentation about the release (release readiness review)
- Demo?
- Create a package for download
- Create an AWS docker image (at some point)
- Create a release version in the code repository, this could be a release branch, or a tag
- Provide documentation as part of the package (and image)
- Provide a channel for communicating about the release, file bugs, etc..
- Gitter channels
- Mailing lists
Storage:
- When ready, merge to Master
- Code is in CI with 1 no-op test:
- Create installer
- Determine the format of the documentation (html, pdf)
- Prolog documentation
- User guide
- Query help docs
- Meet with the community and present the release
- Documentation review
- Demo of features ?
- Code walk through ?
- Create a tag on Master & label release
- Build release package
- Outward facing release communication
- Update RChain.CoOp website to include a section for Storage
- Determine website content - Daniel?
- Create mailing lists
- Create Gitter channels & link on website
- Create link to download the bits on the website
- Griff McClellan (Unlicensed): Advise if anything is missing, and if this approach is reasonable
Issues Capturing the above tasks
Roscala:
For Roscala.Void
- Merge to master
- Code walk through?
- Create tag 'Roscala.Void' on master
- Michael Stay (Unlicensed): Is this approach reasonable for Roscala.Void?
For Roscala.Transition
- Everything as above
- Create a Docker image?