Release checklist (Draft) - Display-Lab/scaffold GitHub Wiki

  1. Versioning:

    Decide on a versioning scheme (e.g., normal Semantic Versioning). Update the version number in your project's source code (e.g., in a version file).

  2. Changelog: Maintain a detailed changelog that lists all changes made since the last release. Ensure each change is categorized (e.g., "Features," "Bug Fixes," "Enhancements"). Link each change to relevant GitHub issues or pull requests.

    • See leakdown tester for an example changelog

  3. Testing: Run thorough tests on your codebase to catch any regressions or issues. Consider using automated testing and continuous integration (CI) tools. Ensure all tests pass successfully.

  4. Documentation: Update or create documentation for new features or changes. Verify that README, user guides, and API documentation are up-to-date. Include instructions for installation and/or usage.

  5. Code Review: Conduct peer reviews to ensure code quality and correctness. Address any feedback or issues identified during the review.

  6. Build Artifacts: Build distributable artifacts (e.g., binaries, packages) for your software. Ensure the build process is well-documented and repeatable.

  7. Tagging the Release: Create a new release on GitHub. Tag the release with the version number. Attach build artifacts to the release

  8. Release Notes: Write release notes summarizing the changes since the last release. Mention notable new features or bug fixes. Link to the changelog for more details.

    • Because changelog isn't being maintained for PFP or KB, may need to just describe everything in a release note, call them release 0.5.0 (aka pre-release) and start changelog from the first release note?

  9. Release Branch or Commit: Consider creating a release branch or marking a specific commit as the release point. This helps in tracking the exact codebase for the release, and for maintaining rollback procedures