VersioningRight - refining the problem by guiding implementation towards the working solution

Advanced VersioningRight

You have decided to continue our VersioningRight journey. “When do we start solving my problem?” you ask? It is already solved. Remember, empty solution is always there for any problem imaginable? What brought you here is you being sure that you can do better than an empty solution. You can do better indeed. Everything is better than an empty solution.

Promotion

Some release snapshots are better than the other ones. How do you know? By version number, that’s for sure - latest snapshots contain more error fixes! How about number of errors found in the snapshot then? Error fixes do not stop testers from discovering new errors even though they tried their best at discovering errors in the first place. That brings the question of how to increase the chance of errors to be discovered after testers did the best job they could. Let’s find out with the help of another new command:

%Repository:repositoryExample> :promoteSnapshot 
    Enter version of the snapshot you want to be promoted: Test/0.1
"repositoryExample" => 
                            x.0                             
                             |                              
                            x.x                             
                             |                              
  -------------------------------------------               
 /       |        |    |    |                \              
x.1     x.2      x.3  x.4  x.6              x.7             
         |                                   |              
     x.x (exp1)                             0.x             
         |                                   |              
        x.5                         -------------------     
                                   /         |         \    
                                  x.8       x.9       x.10  
                                   |         |         |    
                                Test/0.0  Test/0.1  User/0.1

New maturity level! We knew there are more than one maturity level all along. Noticed how version number 0.1 of the latest snapshot has not been changed? Even though version number is the same, version is still different because of different maturity level.

Anyway, what does User maturity level mean? Remember us talking about broader audience that release snapshots target? This is it. The audience even broader than the previous one - actual users of the solution. Let’s find out about other maturity levels that are there adding error fixes for the errors that have been found during the latest user testing phase:

%Repository:repositoryExample> :editBranch 
    Enter version of the branch to edit: 0.x 
    Enter new contents of the branch: content for release
%Repository:repositoryExample> :promoteSnapshot 
    Enter version of the snapshot you want to be promoted: User/0.1 
"repositoryExample" => 
                                       x.0                                        
                                        |                                         
                                       x.x                                        
                                        |                                         
  ------------------------------------------------------                          
 /       |        |    |    |                           \                         
x.1     x.2      x.3  x.4  x.6                         x.7                        
         |                                              |                         
     x.x (exp1)                                        0.x                        
         |                                              |                         
        x.5                         -----------------------------------           
                                   /         |         |               \          
                                  x.8       x.9       x.10            x.11        
                                   |         |         |               |          
                                Test/0.0  Test/0.1  User/0.1  ReleaseCandidate/0.2

Version number got updated now. Is it because of the content? Let’s find out:

%Repository:repositoryExample> :showContent 
    Enter version: Test/0.1
"c0ntent 4 release"
%Repository:repositoryExample> :showContent 
    Enter version: User/0.1 
"c0ntent 4 release"
%Repository:repositoryExample> :showContent 
    Enter version: ReleaseCandidate/0.2 
"content for release"

Yes, content of Test/0.1 and User/0.1 are the same. That indeed looks like snapshot promotion - just upgrading maturity level. Changing version number only if necessary.

What ReleaseCandidate maturity level is about? Name suggests that it is not a final stage of solution release. It is the last chance to find errors before actual distribution of solution among the broadest audience possible. Usually last chance to find subtle errors is giving solution in hands of users that use it for extended period of time. This is to see if there are cumulative errors that appear only if solution is used long enough.

%Repository:repositoryExample> :promoteSnapshot 
    Enter version of the snapshot you want to be promoted: ReleaseCandidate/0.2 
"repositoryExample" => 
                                            x.0                                             
                                             |                                              
                                            x.x                                             
                                             |                                              
  -----------------------------------------------------------                               
 /       |        |    |    |                                \                              
x.1     x.2      x.3  x.4  x.6                              x.7                             
         |                                                   |                              
     x.x (exp1)                                             0.x                             
         |                                                   |                              
        x.5                         ---------------------------------------------------     
                                   /         |         |               |               \    
                                  x.8       x.9       x.10            x.11            x.12  
                                   |         |         |               |               |    
                                Test/0.0  Test/0.1  User/0.1  ReleaseCandidate/0.2  Prod/0.2

Prod means production - solution that is error free, thus ready to be replicated in (high) number of quantities. For mass production, for example. Important aspect of production solutions is that they cannot be changed, only replaced.

Another important aspect of production solution is that at some point we will eventually need to both throw it away and keep it. Why throw it away? Because it somehow turned out you still need a new solution even though there is an existing one that actually solves the problem. Why keep it? There is no choice to keep it or not - it is already out there. What is the choice then? You have already made it while implementing the solution. It resulted in contradiction of the solution with the emerged problem definition. Subtle, innocuous refinement of problem definition sometimes renders whole existing solution useless if updated problem defintion were to be met. That’s when we know we need a support branch.

Support branches

To understand what should be the content of the support branch, we need a contradictory problem definition first. How about following problem definition that contradicts existing solution implementation: Solution should not contain word 'content'? It contradicts not only content of production solution Prod/0.2, but also content of branches and previous snapshots. Let’s examine this situation (turning revisions off beforehand):

%Repository:repositoryExample> :toggleRevisions
"repositoryExample" => 
                                  x.x                                   
                                   |                                    
     ------------------------------------                               
    /                                    \                              
x.x (exp1)                              0.x                             
                                         |                              
                ---------------------------------------------------     
               /         |         |               |               \    
            Test/0.0  Test/0.1  User/0.1  ReleaseCandidate/0.2  Prod/0.2

%Repository:repositoryExample> :showContent 
    Enter version: x.x
    Enter branch name to show content: 
"one more content"
%Repository:repositoryExample> :showContent 
    Enter version: x.x
    Enter branch name to show content: exp1 
"experimental content"
%Repository:repositoryExample> :showContent 
    Enter version: 0.x
"content for release"
%Repository:repositoryExample> :showContent 
    Enter version: Test/0.0 
"cntent 4 rellease"
%Repository:repositoryExample> :showContent 
    Enter version: Test/0.1
"c0ntent 4 release"
%Repository:repositoryExample> :showContent 
    Enter version: User/0.1 
"c0ntent 4 release"
%Repository:repositoryExample> :showContent 
    Enter version: ReleaseCandidate/0.2 
"content for release"
%Repository:repositoryExample> :showContent 
    Enter version: Prod/0.2 
"content for release"

The word ‘content’ is everywhere! Looks like we have made a poor choice putting it there in the first place. It didn’t look as a poor choice back then though. But it definitely looks like one now. From this moment and onwards we promise we will be more careful by avoiding word ‘content’. This is our resolution for future solutions that are going to be totally different. To confirm that solution is based on the resolution, we run command :newSupportBranch:

%Repository:repositoryExample> :editBranch 
    Enter version of the branch to edit: x.x
    Enter branch name to edit content: 
    Enter new contents of the branch: and now for something completely different
%Repository:repositoryExample> :newSupportBranch 
"repositoryExample" => 
                                           x.x.x                                           
                                             |                                             
      ----------------------------------------------------------------------------------   
     /                                          |                                       \  
x.x.x (exp1)                                  x.0.x                                   0.x.x
                                                |                                          
                   -----------------------------------------------------------             
                  /           |           |                 |                 \            
              Test/x.0.0  Test/x.0.1  User/x.0.1  ReleaseCandidate/x.0.2  Prod/x.0.2       

Arghhhhh! Not this again! Version numbers ‘doubled’ before, but now they have ‘tripled’?! How many times will this happen?! Don’t worry, it is the last time this is happenning, we promise.

If you are blown away by version number ‘trippling’, there is another feature of support branches that you will like as well:

%Repository:repositoryExample> :editBranch 
    Enter version of the branch to edit: 0.x.x 
    Enter new contents of the branch: and now for something absolutely completely different
%Repository:repositoryExample> :showContent 
    Enter version: 0.x.x 
"and now for something absolutely completely different"
%Repository:repositoryExample> :showContent 
    Enter version: x.x.x
    Enter branch name to show content: 
"and now for something absolutely completely different"
%Repository:repositoryExample> :editBranch 
    Enter version of the branch to edit: x.x.x
    Enter branch name to edit content: 
    Enter new contents of the branch: and now for something absolutely completely different for now
%Repository:repositoryExample> :showContent 
    Enter version: 0.x.x 
"and now for something absolutely completely different for now"

Once you edit content of the support branch, it appears as a content of mainline and vice versa! As though mainline branch and support branch are the same. Let’s create another support branch to explore this effect more:

%Repository:repositoryExample> :newSupportBranch 
"repositoryExample" => 
                                              x.x.x                                               
                                                |                                                 
      -----------------------------------------------------------------------------------------   
     /                                          |                                       |      \  
x.x.x (exp1)                                  x.0.x                                   0.x.x  1.x.x
                                                |                                                 
                   -----------------------------------------------------------                    
                  /           |           |                 |                 \                   
              Test/x.0.0  Test/x.0.1  User/x.0.1  ReleaseCandidate/x.0.2  Prod/x.0.2              

%Repository:repositoryExample> :editBranch 
    Enter version of the branch to edit: x.x.x
    Enter branch name to edit content: 
    Enter new contents of the branch: and now for something absolutely completely different for mainline
%Repository:repositoryExample> :showContent
    Enter version: x.x.x
    Enter branch name to show content: 
"and now for something absolutely completely different for mainline"
%Repository:repositoryExample> :showContent
    Enter version: 0.x.x
"and now for something absolutely completely different"
%Repository:repositoryExample> :showContent
    Enter version: 1.x.x
"and now for something absolutely completely different for mainline"

If we edit mainline content, the content becomes the same in support branch 1.x.x. But does it have any effect if we edit content of support branch 0.x.x? Let’s find out:

%Repository:repositoryExample> :editBranch
    Enter version of the branch to edit: 0.x.x
    Enter new contents of the branch: and now for something absolutely completely different for 0.x.x
%Repository:repositoryExample> :showContent 
    Enter version: x.x.x
    Enter branch name to show content: 
"and now for something absolutely completely different for mainline"
%Repository:repositoryExample> :showContent 
    Enter version: 0.x.x
"and now for something absolutely completely different for 0.x.x"
%Repository:repositoryExample> :showContent 
    Enter version: 1.x.x
"and now for something absolutely completely different for mainline"

It does not have any effect on any other branches if we edit content of the support branch 0.x.x. What about if we edit the content of the support branch 1.x.x?

%Repository:repositoryExample> :editBranch
    Enter version of the branch to edit: 1.x.x
    Enter new contents of the branch: and now for something absolutely completely different for 1.x.x
%Repository:repositoryExample> :showContent
    Enter version: x.x.x
    Enter branch name to show content: 
"and now for something absolutely completely different for 1.x.x"
%Repository:repositoryExample> :showContent
    Enter version: 0.x.x
"and now for something absolutely completely different for 0.x.x"
%Repository:repositoryExample> :showContent
    Enter version: 1.x.x
"and now for something absolutely completely different for 1.x.x"

If we edit support branch 1.x.x content, mainline branch content becomes the same. Hm. Looks like there is a pattern. Right! It is there. What is it? It might take another support branch to say for sure, but it looks like mainline and latest support branch share content. But no branches shared content before. Why is this happening? Probably support branches are special in the regard of being able to share content. Actually, there is a deeper explanation for this. Together with creating first support branch we revealed another dimension that was hidden. This has happened before, so no surprise. The difference this time is that it revealed not only dimension itself, but also special property of mainline - it has the most flexible content ever! So flexible, that it holds several branches in itself simultaneously. Content of those branches is entangled - it consists of all possible types of changes: essential content, experimental content, error fixes, incompatible content, etc. Once branch of specific type gets instantiated, it ‘unloads’ mainline by allowing changes of specific type happen separately. As long as support branches appear when concept of incompatibility enters the picture, specifics of support branch is that when it happens for the first time, it gets instantiated as a part of mainline without ‘unloading’ or disentanglement. That’s why content of support branch 0.x.x was shared with mainline. When next support branch gets instantiated, mainline content switches to sharing latest support branch content while previous support branch gets disentangled - all previous content of mainline becomes the content of the previous support branch. That’s why it is called support branch - its purpose is to support content of previous major versions. Oooph! Tough stuff!

Now that we have another kind of branch, can we instantiate snapshots using it? Yes. There is a special kind of snapshots we need to be dealing with - support snapshots.

Support snapshots

Let’s run :newSupportSnapshot command on the 0.x.x branch:

%Repository:repositoryExample> :newSupportSnapshot 
    Enter version, which will be used to append new support snapshot to: 0.x.x 
"repositoryExample" => 
                                              x.x.x                                               
                                                |                                                 
      -----------------------------------------------------------------------------------------   
     /                                          |                                       |      \  
x.x.x (exp1)                                  x.0.x                                   0.x.x  1.x.x
                                                |                                       |         
                   -----------------------------------------------------------        0.x.0       
                  /           |           |                 |                 \                   
              Test/x.0.0  Test/x.0.1  User/x.0.1  ReleaseCandidate/x.0.2  Prod/x.0.2              

Nice! New shiny kind of version number! Can we promote it? Let’s try:

%Repository:repositoryExample> :promoteSnapshot 
    Enter version of the snapshot you want to be promoted: 0.x.0
"repositoryExample" => 
                                                    x.x.x                                                     
                                                      |                                                       
      -----------------------------------------------------------------------------------------------------   
     /                                          |                                             |            \  
x.x.x (exp1)                                  x.0.x                                         0.x.x        1.x.x
                                                |                                             |               
                   -----------------------------------------------------------           --------             
                  /           |           |                 |                 \         /        \            
              Test/x.0.0  Test/x.0.1  User/x.0.1  ReleaseCandidate/x.0.2  Prod/x.0.2  0.x.0  Test/0.x.0       

Yes, support snapshots can be promoted. But peculiarity is that maturity level does not start with Test, but with empty value. What is the target audience for such kind of support snapshots? Target audience for this case is authors of the content themselves. Let’s keep promoting:

%Repository:repositoryExample> :promoteSnapshot 
    Enter version of the snapshot you want to be promoted: Test/0.x.0 
"repositoryExample" => 
                                                          x.x.x                                                           
                                                            |                                                             
      -----------------------------------------------------------------------------------------------------------------   
     /                                          |                                                   |                  \  
x.x.x (exp1)                                  x.0.x                                               0.x.x              1.x.x
                                                |                                                   |                     
                   -----------------------------------------------------------           --------------------             
                  /           |           |                 |                 \         /        |           \            
              Test/x.0.0  Test/x.0.1  User/x.0.1  ReleaseCandidate/x.0.2  Prod/x.0.2  0.x.0  Test/0.x.0  User/0.x.0       

And one more time:

%Repository:repositoryExample> :promoteSnapshot 
    Enter version of the snapshot you want to be promoted: User/0.x.0 
"repositoryExample" => 
                                                          x.x.x                                                           
                                                            |                                                             
      -----------------------------------------------------------------------------------------------------------------   
     /                                          |                                                   |                  \  
x.x.x (exp1)                                  x.0.x                                               0.x.x              1.x.x
                                                |                                                   |                     
                   -----------------------------------------------------------           --------------------             
                  /           |           |                 |                 \         /        |           \            
              Test/x.0.0  Test/x.0.1  User/x.0.1  ReleaseCandidate/x.0.2  Prod/x.0.2  0.x.0  Test/0.x.0  User/0.x.0       

Nowhere to promote anymore. Maturity levels for support snapshots start with empty one and end with User. What if we want to release production version of our solution? For that we will need to create a release branch. Think about it - support branches allow any kind of change to content unlike release branches, which allow only error fixes. Purpose of the support branch is to add meaningful content for solution, while purpose of the release branch is to polish that solution. Let’s check out how releasing from a support branch looks like:

%Repository:repositoryExample> :newReleaseBranch 
    Enter version, which will be used to append new release branch to: 0.x.x 
"repositoryExample" => 
                                                              x.x.x                                                              
                                                                |                                                                
      ------------------------------------------------------------------------------------------------------------------------   
     /                                          |                                                      |                      \  
x.x.x (exp1)                                  x.0.x                                                  0.x.x                  1.x.x
                                                |                                                      |                         
                   -----------------------------------------------------------           ------------------------------          
                  /           |           |                 |                 \         /        |           |         \         
              Test/x.0.0  Test/x.0.1  User/x.0.1  ReleaseCandidate/x.0.2  Prod/x.0.2  0.x.0  Test/0.x.0  User/0.x.0  0.0.x       

%Repository:repositoryExample> :newReleaseSnapshot 
    Enter version, which will be used to append new release snapshot to: 0.0.x 
"repositoryExample" => 
                                                                x.x.x                                                                 
                                                                  |                                                                   
      -----------------------------------------------------------------------------------------------------------------------------   
     /                                          |                                                         |                        \  
x.x.x (exp1)                                  x.0.x                                                     0.x.x                    1.x.x
                                                |                                                         |                           
                   -----------------------------------------------------------           --------------------------------             
                  /           |           |                 |                 \         /        |           |           \            
              Test/x.0.0  Test/x.0.1  User/x.0.1  ReleaseCandidate/x.0.2  Prod/x.0.2  0.x.0  Test/0.x.0  User/0.x.0    0.0.x          
                                                                                                                         |            
                                                                                                                     Test/0.0.0       

Did you notice the difference between support snapshots and release snapshots? Unlike release snapshot version numbers (0.0.0), support snapshot version numbers (0.x.0) even look ‘incomplete’ with that x in the middle instead of a number. So, by all means, support snapshots are intermediate solutions targeted at rather narrow audience.

What’s next

Now that you have learned a lot about problem solving evolution model, do you want VersioningRight to be built? Let me know! Or, alternatively, sign up for VersioningRight Newsletter below: