Skip to main content

General Release Cycle Guidance

This guide outlines the release cycle for the Osborn project, aligning Omnicom's general guidance with our specific development workflow using develop, stage, and main branches.

Version Control​

Osborn uses a three-numeric-dot code release notation system:

Major.Minor.Patch

For example, 2.3.34 denotes the Second Major Release, Third Minor Release, and Thirty-fourth Patch Release.

Major Release​

  • Definition: A substantial modification to existing code or the addition of new modules that requires more than 40% code rewrite or significant development effort.
  • Scope: In Osborn, a major release could be a significant refactoring of the Django backend, a rewrite of the frontend state management, or the introduction of a new core service.
  • Workflow:
    1. Development happens over multiple sprints in feature branches (OPD-xxx) that are merged into develop.
    2. Once all features for the major release are complete and stable in develop, a release branch is created.
    3. This release branch is merged into stage for extensive QA and UAT.
    4. Finally, it is merged into main for the production release.
  • Versioning: Major releases result in updating the major release number (e.g., 1.x.x to 2.0.0).

Minor Release​

  • Definition: Modifying existing code or adding new, non-breaking functionality within existing modules.
  • Scope: Most new features in Osborn are considered minor releases. These are developed in individual Jira tasks.
  • Workflow:
    1. A feature branch (OPD-xxx) is created from develop.
    2. Once complete, a Pull Request is created to merge the feature back into develop.
    3. After passing all CI/CD checks and reviews, the code is merged.
    4. Periodically, the develop branch is merged into stage and then main to release a collection of new features.
  • Versioning: Minor releases result in updating the minor release number (e.g., 2.2.x to 2.3.0).

Patch Release​

  • Definition: The repair of solution issues (bugs) within the current release.
  • Scope: A patch release is only to fix existing code and does not include new functionality.
  • Workflow:
    • Standard Bugs: Handled like a minor release, with a fix/OPD-xxx branch created from develop and merged back via a PR.
    • Hotfixes: For critical production bugs, a hotfix/OPD-xxx branch is created from main. After fixing and testing, it is merged directly into main, stage, and develop as described in the Development Workflow.
  • Versioning: Patch releases result in updating the patch release number (e.g., 2.3.33 to 2.3.34).