Skip to main content

Identify Release Scope

Before starting a release, it is important to identify the scope of the release. This includes determining which products, bugfixes, and features will need be included in the release.

Generally, a Product Release Request is requested by the Product Manager, who also determines the scope of the release. Due to feature testing and bugfix verification processes, the code in the develop branch of the repository may not align with the release scope. Incorrectly including unverified/ unintended features or bugfixes in a release can lead to issues in the production environment and may even cause data loss for end-users. Therefore, it is crucial to review the Product Release request and ensure that the codebase reflects the intended release scope.

In practice, this is a tedious and error-prone process to manage, as slightest error in the release scope identification could cause an incomplete or erroneous release. That is the reason why we start our Release Scope Identification step by gathering the information about the changes made in the develop branch since the last release. This changelog is then verified with the Product Managers to identify changes that should not be included in the release.

Steps to Identify changes in the Codebase​

  1. In the Release Channel, locate the release note of the latest release made for the product(s) to be released.

  2. Identify the release branch associated with the latest release.

    • The branch name always include the code version, prefixed by release/ and the abbreviations of the released product(s), like release/lf/2025.9.10 .
    • Sometimes, multiple products are released together, in which case the branch name will include multiple product abbreviations. As an example: release/lf-sa-la/2025.9.10 refers to products Lux FinTax, Smart Audit and Lux Audit being released all with version number 2025.9.10.
    • Refer to Product Abbreviations for a list of product abbreviations and Grouped Releases for more information on grouped releases.

  3. Identify changes to the last release.

    • With GitHub
    • With IntelliJ
    • With Visual Studio Code
    • With Git CLI

  4. Interpret the changes. A combination of the following will provide enough context and information to infer changes to the repo.

    • Commit Messages
    • Code Changes
    • Trello Board

  5. Based on the inferred knowledge, briefly document individual changes in each component. Ideally, the changes should be documented as follows:

    • In case of a single change within a component
      • [Component Name]: Brief explanation of the change.
    • In case of multiple changes within a component
      • [Component Name]
        • Brief explanation of change 1
        • Brief explanation of change 2
        • ...

  6. Submit the changelog to the Product Manager to verify for any missing/ unintended feature or bugfix.

    note

    We are evaluating a pre-release Teams Channel to allow all Product Managers to view and to sign off the changelog to be released.

    • In case of any unintended features present in the codebase prior to release, follow the instructions in the section Code Rollback to revert any unintended changes.

Release Deadline​

The standard CWI release deadline is every Friday of the week at 5 PM EDT (10 PM CET). A release

In practice,

Exceptions to this rule exist, but they should be used sparingly to avoid unsuccessful releases and to maintain a consistent release schedule.