Section 12 ‐ Release Management - ApertureViewer/Aperture-Opertations-Manual GitHub Wiki

Release Management encompasses the processes and procedures for preparing, building, versioning, and distributing official public releases of Aperture Viewer. The goal is to deliver stable, high-quality updates to users in a predictable and well-documented manner.

12.1 Release Cadence Philosophy

Aperture Viewer aims for a release cadence that balances timely delivery of new features and improvements with thorough testing and stability.

  • Feature-Driven Major/Minor Releases:
    • Major version releases (e.g., v1.0.0, v2.0.0) and significant minor version releases (e.g., v1.1.0, v1.2.0) will typically be feature-driven. They will be planned around the completion and stabilization of a significant set of new features, major enhancements, or architectural changes outlined in the project roadmap.
  • Hotfix Releases (Patch Releases):
    • Patch version releases (e.g., v1.0.1, v1.1.1) will be issued as needed to address critical bugs, security vulnerabilities, or minor regressions discovered shortly after a major/minor release.
    • The aim is to release hotfixes relatively quickly after the identification and verification of critical issues.
  • Targeted Release Cycle (Post-Hotfix):
    • Following a major release and any immediate hotfixes, the project aims for a subsequent minor or major feature release approximately every 4 to 6 weeks, contingent upon the completion and QA validation of planned features. This is a target and may be adjusted based on development progress and QA findings.
  • Flexibility: This cadence is a guideline. The ultimate decision to release is based on the readiness and quality of the build, as determined by the Project Lead in consultation with the Head of Quality Assurance, rather than strict adherence to a calendar date.

12.2 Versioning Scheme

Aperture Viewer adheres to Semantic Versioning 2.0.0 (SemVer) for its public releases. The version format is MAJOR.MINOR.PATCH (e.g., v1.0.0, v1.0.1, v1.1.0).

  • MAJOR version (X.y.z): Incremented when incompatible API changes are made (less common for a viewer application itself, but could apply to internal architectural changes that significantly alter plugin compatibility if such a system existed) or when very significant new functionalities or paradigm shifts are introduced that represent a major evolution of the viewer.
  • MINOR version (x.Y.z): Incremented when new functionality is added in a backward-compatible manner, or when significant enhancements or improvements are made to existing features. Most feature releases will likely be MINOR version updates.
  • PATCH version (x.y.Z): Incremented when backward-compatible bug fixes are made, or for very minor, self-contained improvements. Hotfix releases will be PATCH version updates.

Build metadata or pre-release identifiers (e.g., -alpha, -beta, -rc1) may be appended for internal or pre-release test builds but will not typically be part of the official public release tag.

12.3 Release Preparation Steps (Lead: Project Lead, Support: Head of QA)

The following steps are undertaken to prepare for an official public release:

  1. Feature Freeze: Once the planned features for a release are implemented on the dev branch and have passed initial developer testing, a "feature freeze" is declared. No new features will be added to this release cycle; focus shifts entirely to bug fixing, stabilization, and polishing.
  2. Create Release Branch:
    • A new release/vX.Y.Z branch (e.g., release/v1.1.0) is created from the current state of the dev branch.
    • All further bug fixes specifically for this release will be committed to this release branch.
  3. Intensive QA and Bug Fixing:
    • The Head of QA and any testing team conduct comprehensive testing on builds from the release branch (as outlined in Section 11.5 - Release Candidate Testing Process).
    • Bugs identified are reported, prioritized, and fixed by the Project Lead on the release branch.
    • Fixes made on the release branch are also cherry-picked or merged back into the dev branch to ensure dev remains the primary line of ongoing development.
  4. Update Version Information:
    • All internal version numbers within the codebase (e.g., in VIEWER_VERSION.txt, build scripts, CMakeLists.txt, UI "About" dialogs) are updated to reflect the new release version (e.g., from 1.0.0 to 1.1.0). This is a dedicated commit on the release branch.
  5. Changelog Compilation:
    • The Project Lead, with input from the Head of QA and by reviewing commit messages since the last release, compiles a detailed changelog.
    • The changelog should categorize changes (New Features, Enhancements, Fixes, Upstream Sync, Known Issues, Technical/Build) and provide clear, user-understandable descriptions. Markdown format is preferred.
  6. Final Build and Sanity Check: A final build is created from the release branch after all critical fixes and version updates are committed. A last round of smoke testing/BVT is performed.
  7. Tagging the Release:
    • Once the final build is confirmed stable, the Project Lead creates an annotated Git tag on the final commit of the release branch (e.g., git tag -a v1.1.0 -m "Aperture Viewer v1.1.0").
    • The release branch and the new tag are pushed to the official GitHub repository (e.g., git push origin release/v1.1.0 --tags).

12.4 Building Release Installers/Packages

  • Official release installers (e.g., Windows .exe installers) are built by the Project Lead from the exact commit tagged for the release on the release/vX.Y.Z branch.
  • Builds are performed in a clean, dedicated build environment to ensure consistency and avoid contamination from development artifacts.
  • The build process uses NSIS (Nullsoft Scriptable Install System) for Windows installers, utilizing the project's .nsi script.
  • SHA-256 checksums are generated for all official release installer files.

12.5 Release Publication (GitHub Releases)

  • A new Release is created on the ApertureViewer GitHub repository, associated with the new version tag.
  • Release Notes: Engaging summary of release highlights, key features, and any critical information for users.
  • Download Links: Direct links to the built installer packages uploaded to the GitHub Release assets.
  • Changelog: The full, detailed changelog (or a link to it on the Wiki) is included.
  • SHA-256 Checksums: The SHA-256 checksums for the installer files are published for user verification.
  • Link to Wiki: Links to relevant Wiki pages (e.g., Download & Installation, Getting Started, Troubleshooting).

12.6 Post-Release Merging

  • The release/vX.Y.Z branch (containing version number updates and any last-minute release-specific fixes) is merged back into the dev branch to ensure dev reflects the latest released state plus ongoing development.
  • The release/vX.Y.Z branch may also be merged into master if master is maintained as a reflection of the latest pristine Firestorm upstream code plus official Aperture release changes. (This needs careful consideration based on how master is used; if master is strictly for upstream Firestorm, then only dev receives the merge from release).

12.7 Community Communication of Release

(This will be managed by the Community & Social Media Manager, as per the Social Media Roadmap - Appendix [H]. Key elements include:)

  • Discord Announcement.
  • Update GitHub README.md.
  • Update Wiki Home page.
  • Posts on other relevant social media platforms (Primfeed, etc.).