Release Level Clone

Spira supports a functionality to clone the release. This can be located in the detailed view within a release as shown below. 

What does the Release Clone do?

The following table summarizes what Spira supports. 

The reason for not bringing some of the artifacts and associated data to the new release lies in the generic framework of software development process.  

V-Model to Product Development

The V-Model to software development is extensible for both plan-driven (traditional) and change-driven (adaptive) approaches.  

According to this model,  when requirements are released over time in multiple releases, the elements of regression testing is done using integration testing and system testing. Since the releases or sprints are meant to support new requirements along with previously released functionality, the verification of new requirements and validation previously functionality are both tested. Hence the requirements of the previously releases are not required but the test cases are required. 

As the test cases themselves will be executed as part of regression in every release, the test runs of previous test case execution are not relevant. As scenario testing (collection of test cases) in the form of test sets are specific to business processes and may change in every release, test sets are not copied.

 The tasks represent activities to complete the "Definition of Done" for a requirement, the tasks are not required. The defects (and therefore incidents) detected in a release is also not required unless they are planned to be fixed in a specific release. Since the defect triaging process determines the planned release of an incident, any unresolved incident need not be automatically copied in a release.  

The comments, followers, and history associated with these artifacts are also not relevant and brought forward consequently to the cloned release.