MyBB Documentation

Release Workflow

  1. Source Code

    These changes can be applies during normal development in the public repository, or as patches stored in the data repository and applied to final packages by the build script.

    • Version Metadata

      MyBB’s version and the corresponding version code (digit-only format) is hardcoded in multiple locations:

      • MyBB::$version, MyBB::$version_code (inc/class_core.php)

        Indicates the current version. As a result, a modified inc/class_core.php file is always included in the update package.

      • $langinfo['version'] in the English language manifest (inc/languages/english.php)

        Indicates the latest version in which changes to language phrases occurred. If no phrases were modified, this values is left unchanged.

      • version attributes of <theme>, <stylesheet>, <template> (install/resources/mybb_theme.xml)

        Indicates the latest version in which changes to the default theme occurred, and in specific stylesheets and templates. If the theme was not modified, these values are left unchanged.

    • Update File

      Modified templates and settings should result in a install/resources/upgrade*.php file created for the upgrade process (no custom code is needed for synchronization of templates and settings). See examples.

      The file’s comment is parsed by the upgrade script, and should indicate which previous versions the script applies to.

  2. Repository Maintenance

    • Public Repositories

      Issue and Pull Requests are reviewed to ensure that:

      • the version Milestone doesn’t contain unresolved entries,
      • all Issues resolved after the previous version are assigned to the new version’s Milestone,
      • correct metadata is attached to Milestone entries (i.a. closed; s:resolved label).

      The final public commit for the version is marked with a signed mybb_*_build git tag.

    • Internal Repositories

      Final security patches (if any) are added to the data repository on the mybb_*_build branch.

  3. Pre-Release Public Testing

    The mybb_*_build git tag is used to provide downloadable packages of the final codebase that excludes non-public patches.

    1. A pinned announcement thread is created in the Development forum.

      Values copied from the internal Getting * Ready thread:

      • Comment, basing on the comment value in Additional values for version .md (if present; converted from Markdown to MyCode)
      • Testing focus list, basing on Public QA focus (if present)

    2. The link is shared and pinned in the public Discord #18-development channel.

    Codebase changes applied after the announcement are noted in the thread.

    The recommended minimum waiting period between the announcement and the version’s final release is 7 days.

  4. Package Building and Testing

    The mybb/mybb-build build script is used to perform tasks related to preparing releasable packages and associated information.

    1. The mybb/mybb-build repository is downloaded.
    2. Previous content of input/patches/ is deleted (if any).
    3. The build properties in the input/build.properties file are configured:
      • targetVersion: the version number
      • sourceRepositoryBranch: the tag/branch in the mybb/mybb repository; usually mybb_*_build, or mybb_* pointing to a previous MyBB version for a security-only release
      • inputFilesRepositoryBranch: the branch in the data repository; usually mybb_*_build, or master if no patches are necessary
      • includeInstallInUpdateSet: true if running the upgrade script is required, false otherwise
      • packageDate: the build date (GMT+0)
    4. The build process is run.
    5. The build log is verified.
    6. The input/ and output/ directories are added to a build_*_rc*.zip archive (indicating the version code and the Release Candidate number).
    7. The created archive is signed with the Team member’s public key.
    8. A post is added to the Getting * Ready thread, including:
      • tags and commit hashes of repositories used during the build process:
      • downloadable package and the Team member’s signature
      • Release Candidate (RC) number
    9. A link to the package post is added to the Packages list in the first post: 
      https://... RC1 (YYYY-MM-DD 00:00)

      Links to posts with previous packages are crossed out ([s]...[/s]).

    10. The link to the package post is posted in the internal Discord #staff-18-organization channel, indicating the RC number.
    11. The packages are tested by Team members according to the Internal QA focus list in the Getting * Ready thread.

    The recommended minimum waiting period between the last Release Candidate is added and the version’s final release is 3 days.

  5. Announcements Preparation

    The package- and version-related information is completed and verified internally:

    • Updates to the MyBB.com website (mybb/mybb.com):
      • _versions/*.md version metadata for Release Notes, combined from:
        • the partial *.md file generated by the build script
        • Additional values for version .md from the Getting * Ready thread
      • checksums/release_mybb_*.txt checksums file, fully generated by the build script.
    • Release Blog Post, with:
      • the title and content generated by Jekyll basing on the version metadata at /versions/release-blog-post/ (locally), separated by a --- line,
      • the author set to MyBB Team,
      • tags Release, Updates, and Security if the release addresses security-related issues.
    • Updates to the Docs.MyBB.com website (mybb/docs.mybb.com):

  6. Publication

    The packages and associated information are published. These tasks should be executed without unnecessary delay.

    1. The packages are uploaded to resources.mybb.com and verified.
    2. The MyBB.com website is updated by pushing new files to the mybb/mybb.com repository:
      • _versions/*.md version metadata (producing Release Notes and updating MyBB.com latest version information),
      • checksums/release_mybb_*.txt checksums.

      The new mybb.com/download page and the version’s Release Notes are verified.

      The download links for packages on the Release Notes page are verified.

    3. The Release Blog Post is published.
    4. A link to the Release Blog Post is posted in:
      • @[email protected] on Mastodon (automated by WordPress.com),
      • @mybb on Twitter,
      • @mybbsecurity on Twitter (security releases only), indicating the number of addressed vulnerabilities per severity: 
        MyBB 1.8.x addressing (...) high, (...) medium, (...) low risk vulnerabilities has been released. https://blog.mybb.com/...
      • public Discord #18-support channel (pinned message; links related to previous versions are unpinned).

  7. Repository Updates

    1. Synchronization commits, based on individual non-public patches are pushed to the public repository (if any).
    2. The resulting mybb/mybb repository state is tagged (signed mybb_18xx git tag indicating the version code).
    3. A Release is created and all packages are attached (mybb_*.zip, changed_files_*.zip, and build_*.zip, containing the input and output of the build script).

    4. GitHub is added to the list of package locations in the version metadata file:

        locations:
    - name: github.com/mybb/mybb/releases/

  8. Advisory Publication

    1. Security Advisories for addressed vulnerabilities are published.
    2. Links to published Security Advisories are added to:

      • the Release Blog Post:

        Medium risk: Example vulnerability (<a href="...">advisory</a>) — reported by ...

      • the Release Notes:

        references:
  - url: ...
    title: "Advisory: ..."
    type: advisory

    3. Titles and links to published Security Advisories are added as replies to the @mybbsecurity version announcement tweet:

      Advisory: ... https://...

  9. Archiving

    The Release Notes and Release Blog Post pages are archived using web.archive.org.

  10. Documentation & Forum Updates

    1. Documentation

      • The plugin hooks data (_data/mybb18_plugin_hooks.yml) is pushed to the Docs repository.
      • The version Milestone is closed.
      • A new Milestone is created for the next version.

    2. Community Forums & Discord

      • Public
        • The Pre-Release thread is unpinned and locked.
        • The link to the Pre-Release thread in the public Discord #18-development channel is unpinned.

    3. Third Parties

      • Security Workflow
        • Reporters of addressed security issues are contacted.
        • CVE update requests are submitted to relevant CNAs.

    4. Internal

      • The Post-release tasks list is checked.
      • A link to the Release Blog Post is posted in the Getting * Ready thread.
      • The Getting * Ready thread is unpinned.
      • A new Getting * Ready thread is created and pinned.

Edit this page on GitHub

Copyright © 2002-2024 MyBB Group