Quantcast
Channel: PureCM Blog
Viewing all articles
Browse latest Browse all 13

Creating Versions Retrospectively

$
0
0

PureCM has always had the ability to create streams from a previous changeset but this has been made much simpler with the 2014-2 release.

Create a Version from the Version History

 

Suppose you are working on Version 2 and have already submitted features A, B and C. You are currently working on feature D.


You now realise that you want to release Version 2 with features A, C and D. You want to release feature B into Version 3.


You can do this by first renaming Version 2 to Version 3. You can then go to the history for Version 3 and select ‘Create Version From’ on the feature A changeset and call it Version 2.


You can now merge feature C from Version 3 into Version 2. So Version 2 now contains features A and C. All developers can now switch their workspace to the new Version 2 and carry on working on Feature D.

You might also consider creating the merge rules ‘Version 1->Version 2’ and ‘Version 2->Version 3’, making submitted changesets pending. This will ensure that submitted changesets are propagated down to the child versions.

You probably also want to delete the merge rule ‘Versions 1->Version3’. Typically you will not want to merge changesets directly from Version 1 to Version 3 – bypassing Version 2.


Create a Release from the Version History

 

You can also create a release from a changeset in the version history. Simply go to the changeset in the version history and select ‘Create Release From’.


This will create a release including all the changesets up to and including the selected changeset. Later changesets will not be included.


Create a Version from a Release

 

Another new feature of the 2014/2 release is the ability to create a version from a release. Select the release you want to create a version from and select ‘Create Version From’.

A classic example where this is useful is where you create a release (Release 1.1) from Version 1 and carry on submitting features into Version 1 which will go into Release 1.2. A bug in Release 1.1 now means you need to create Release 1.1.1 as soon as possible. You do not want to include the new features submitted in Version 1 because they have not been tested. The priority is fixing the bug.

So you will create the Version 1.1 from the Release 1.1.


You will then submit the bug fix into Version 1.1. You can then create Release 1.1.1 from Version 1.1. Finally you must not forget to merge the bug fix back into Version 1. It is probably worth creating the merge rule ‘Version 1.1->Version 1’.


Viewing all articles
Browse latest Browse all 13

Latest Images

Trending Articles





Latest Images