Projects and Solutions

HomeKnowledge BaseAdminProjects and Solutions

Version (Baseline) Management

734 views /  2 likes /  // admin/

OVERVIEW

Version Baseline Management is essential for tracking and controlling your project versions, ensuring you can always refer to specific points in time during your project’s development lifecycle. Orcanos provides a robust system for handling baselines effectively.

PROJECT/ SOLUTION VERSION – WHAT IS A VIEW

  • When you open an ALM project in Orcanos, it is assigned version 1.0 by default.
  • The combination of project and version is called a “View.”
  • A View typically represents a specific component of your product with a specific version.
  • Users can log in to a specific project and version (e.g., Cardiology Monitor 5.6).
  • The Orcanos version field (system field) supports a 4-digit format: Major.Minor.Release.Build.
  • The View can be based on 2 or 3 digits (e.g., Cardiology Monitor 5.6 or Cardiology Monitor 5.6.1).
    • You can switch from 2 digits to 3 digits, but once you use 3 digits, you cannot revert to 2 digits.
  • You can advance the project version to a higher version (e.g., from 1.0 to 1.1 or 2.0).
    • When advancing the version, the system creates a new View (e.g., 2.0) based on the previous baseline (1.0).
    • Users can then log in to either 1.0 or 2.0.
  • All content from 1.0 is transparently available in the new version (2.0).
    • The content isn’t transferred, but Orcanos uses smart pointers to manage the changes (i.e., added, changed, or deleted items) between each baseline.

POOL – BACKLOG

  • Items created in the Work Items view are added to the Pool (Backlog).
  • These items are not assigned to any specific view (version).
  • You can move items between the Pool and a View as needed.
  • Branched items cannot be placed in the Pool.
  • Pool items do not appear in the product tree and cannot have any hierarchy.

VERSION VIEW – FULL USE CASE

For example, let’s say you open a new project in Orcanos called Cardiology Monitor.

  • You add two requirements to the project.
  • Both requirements are included in Baseline 1.0.
  • You can view the version information in the Product Tree.

Now, let’s open Version 2.0 (in Admin).

  • Since no changes were made, the content in Version 2.0 is identical to Version 1.0.
  • As a result, the version next to the item name in the Product Tree still displays 1.0.

Now, let’s freeze Version 1.0 in the Admin settings.

  • When a version is frozen, no further changes can be made to that version.

Any changes made to items created in Version 1.0 while we login to 2.0 will cause the items to branch.

  • The version of the changed item will be 2.0
  • The content of the item in 1.0 is unchanged

Adding a new item while logged into Version 2.0 will create the item exclusively in Version 2.0.

  • The version of the newly created item will be 2.0.

The image below shows how you can branch an item:

 

Lets move on.

You can now open Version 3.0 while keeping Version 2.0 open, allowing you to work on both versions in parallel.

  • Any changes made in Version 2.0 will automatically appear in Version 3.0.
  • Changes made in Version 3.0 will follow the same behavior as described earlier (i.e., adding a new item or branching an existing item).

Note: When making changes to an item in Version 3.0, you also have the option to save it to the original view (i.e., Version 2.0), so the item is updated in both 2.0 and 3.0.

  • This means the item will not be branched.

    If 2.0 is locked – the system will force a branch

  • For more details on handling different cases, please refer to the information below.

Refer to the image below to see how versions are displayed in Orcanos.

USE CASE #1: WORKING ON NEXT GENERATION WHILE CURRENT GENERATION RELEASES ARE UNKNOWN

There are cases when we are currently on 1.0, we have a team that wants to work on the next generation (2.0), but we know we will have 1.1, 1.2, 1.3…and we don’t know how many and we don’t know when these versions will become relevant.

The challenge here is, that we don’t know how many minors we will have in 1.x, and we know that release 2.0 will be based on the latest (unknown) 1.X, which could be 1.3, 1.4, etc.

The solution here is manual.

  1. We will create the future versions ahead of time, which means creating 1.1, 1.2, and 1.3, assuming we won’t exceed a specific number of versions.
  2. Then we create version 2.0
  3. Then we disable 1.1, 1.2, 1.3… so the user can only see 1.0 and 2.0
  4. Every change we do in 1.0 will be available in all versions. Every change we do in 2.0 will only be seen in 2.0
  5. now we enable 1.1. so all content of 1.0 is shown there. we make changes in 1.1 – all changes will be applied to 1.2, 1.3, 2.0 but not in 1.0

Use Case #2: We created Version 2.0 but now realize we need to add earlier releases (1.1, 1.2, etc.)

If no items were added to Version 2.0, follow these steps:

  1. Go to Admin -> Project -> Versions and change the version label from 2.0 to 1.1.
  2. Add new versions (1.2, 1.3,…1.5).
  3. Create Version 2.0 again.
  4. Now you have Versions 1.1, 1.2, and 2.0 (all identical).
  5. Hide versions 1.2, 1.3, etc., and keep only 1.0, 1.1, and 2.0 active.

Use Case #3: We created Version 2.0 but now realize we need to add earlier releases (1.1, 1.2, etc.), and minor changes have already been made in 2.0

If items were already added to Version 2.0, follow these steps:

  1. Go to Admin -> Project -> Versions and change the version label from 2.0 to 1.1.
  2. Add new versions (1.2, 1.3,…1.5).
  3. Create Version 2.0 again.
  4. Now you have Versions 1.1, 1.2,1.3… and 2.0 (all identical).
  5. Move the items labeled as 1.1 from 1.1 to 2.0 using the “Move to view“ option.
  6. Now, Versions 1.0, 1.1, 1.2, etc. are identical, and Version 2.0 has the same data it had before.
  7. Hide Versions 1.2, 1.3, etc., and keep only 1.0, 1.1, and 2.0 active.

Use Case #4: We created Version 2.0 but now realize we need to add earlier releases (1.1, 1.2, etc.), and lots of changes have already been made in 2.0

In that case, please contact our team to run a script and add 1.1, 1.2, 1.3 versions for you

HANDLING AND ENABLING BRANCH

  • To enable branching, you can set the “Allow Branch on Change” option at the project level. If this option is not enabled, the branch feature will not be available.

  • The user can choose whether to create a branch or save the changes to the original view. This is only possible if the previous version’s view is not locked.
  • Example:
    • If an item was created in Version 1.0, and the user logs into Version 2.0 and makes a change, they have two options:
      • Save: The item will be saved to Version 1.0, and the version will remain 1.0.
      • Branch: The system will create a branch for the item.
  • FORCE BRANCH: To force users to create a branch and keep data in the previous version unchanged, you can adjust the work item permissions using the “Force Branch [Work Item]” setting.

Force branch is managed in the Group for each work item

Note: If a previous version is locked – the only option user has is “Force Branch”

If previous version is not locked and Not active – the user can choose if to save or branch

ADVANCE PROJECT VERSION

Advance/edit project version – you can open new version, lock version for login, edit version number, freeze version for changes, delete version

HANDLE VERSION PERMISSIONS

  • Orcanos allows you to specify which groups can work on specific versions.
  • This configuration can be managed in the Admin section, under Project->groups

CANCEL BRANCH

  • In cases where a branch was created by mistake, you can revert this action and cancel the branch.
  • To do this, select the item in the tree view, right-click, and choose “Cancel Branch”.
  • This action will revert the item back to the previous version.
  • All branch changes will be removed but will exist in history

Cancel branch is not available for DEFECT Work Item

Cancel Branch of Item Branched Twice:

In a scenario where a work item was branched in Version 1.1 and then branched again in Version 1.3:

  • If the user cancels the 1.3 branch, the 1.1 branch will still exist, and the item will show as branched in Version 1.1.
  • To fully revert back to Version 1.0, you will also need to cancel the 1.1 branch.

FAQ

  • Can I switch from 2 digits to 3 digits?
    • Yes.
  • Can I switch from 3 digits back to 2 digits?
    • No, once you change to 3 digits, you cannot revert to 2 digits.
  • Why can’t I modify the first 2 digits when I log in?
    • The first 2 (or 3) digits represent the view you’re logged into, which is the project’s baseline. Therefore, it cannot be changed.
  • How can I move items to a different view if needed?
    • You can use the “Move To View” option to move items to different views.
Tags:
Related Articles