VersioningRight details

Introductory remarks, basic terminology and conventions

If you had a chance to work with version control systems (such as git, svn, etc), you might notice that a lot of VersioningRight concepts have the same name as version control concepts (repository, branch, commit, revision, merging etc). This is because those concepts have the same meaning in scope of VersioningRight as in other version control systems (VCS). This is also because VersioningRight can be considered a standalone VCS too even when not used in conjunction with other VCSs by enhancing their functionality. At the same time, some concepts get a new name. Such as, for example, snapshots is another VersioningRight name for tags. This is because concept of tags does not fully deliver the right meaning when used in context of VersioningRight.
There is a prototype of VersioningRight with command-line interface that will be used for illustrating VersioningRight specifics and diving into VersioningRight details. In order to start with demonstration, we need to have a repository - place for keeping track of solutions to a specific problem. Example of empty VersioningRight repository for demonstration purposes gets initiated behind the scenes. Thus, all snippets in provided examples have a following prompt: %Repository:repositoryExample>, where Repository is a current editing mode and repositoryExample is a name of selected repository. Usually name of selected repository represents short problem name. In our case this is repositoryExample because the problem at hand is a demonstration of functioning of simplest VersioningRight repository and, with that, core principles of VersioningRight.
Solution is a common VersioningRight term unifying such concepts as actual solution (as in problem solving), document (as in editing), material (as in writing), application (as in software development).
Current VersioningRight prototype operates based on simple unformatted text content that represents the concept of document - the simplest case of solution.
Version in VersioningRight is a unique descriptor of the solution in scope of a single repository.
Command is a string starting with colon that appears after the prompt. For example, :show. In rare cases arguments to the command are supplied at the same line as the command itself, but most of the time command is followed by subsequent command prompt(s) asking to specify command arguments. One of the examples of command with command prompts is :editBranch. Command prompts appear after the command on separate lines prefixed by ‘\t’ character and followed by colon:

    Enter version of the branch to edit:

    Enter new contents of the branch:

In most cases command prompts are equipped with contextual autocompletion functionality that is triggered in command-line mode by pressing tab key. Suggestions for autocompletion appear at the new line after the prompt separated by ‘\t’ character:

    Enter version, which will be used to append new support snapshot to: 
0.x.x  1.x.x

In the case of triggered autocompletion, actually supplied command prompt argument value appears on duplicate command prompt line after the colon:

    Enter version, which will be used to append new support snapshot to: 1.x.x

If command results in updated version tree of repository (most cases) or outputs version tree (:show command), command output is a repository name surrounded by quotes, followed by => sign and simple visualization of latest state of repository in a form of a version tree:

"repositoryExample" => 
   x.x.x    
     |      
   ------   
  /      \  
0.x.x  1.x.x

Otherwise (command does not modify version tree) command output is either the requested value itself or no output at all.

Snippet is formed as a sequence of prompt with specific command, corresponding command prompt(s) (if necessary) with argument values (possibly interspersed by autocompletion suggestions) and corresponding command output:

%Repository:repositoryExample> :show
"repositoryExample" => 
   x.x.x    
     |      
   ------   
  /      \  
0.x.x  1.x.x

%Repository:repositoryExample> :showContent 
    Enter version: x.x.x
"some content"

%Repository:repositoryExample> :newSupportSnapshot 
    Enter version, which will be used to append new support snapshot to: 
0.x.x  1.x.x
    Enter version, which will be used to append new support snapshot to: 1.x.x 
"repositoryExample" => 
   x.x.x    
     |      
   ------   
  /      \  
0.x.x  1.x.x
         |  
       1.x.0

Basic commands

First simplest snippet of :show command run on empty initial repository:

%Repository:repositoryExample> :show
"repositoryExample" => 
x

As you might have noticed, :show command does not have command prompts. This is because it does not require input/arguments. Not only in this particular case, but ever. In that sense :show is a simplest command possible in VersioningRight. It just shows visualization of current state of the repository in a form of a version tree. As long as repository has initial state, version tree looks as x. This is because there is only one solution provided (the one with unique descriptor x), which is, in fact, empty:

%Repository:repositoryExample> :showContent 
    Enter version: x 
""

Let’s fix it by using :editBranch command on the only solution we currently have - x:

%Repository:repositoryExample> :editBranch 
    Enter version of the branch to edit: x 
    Enter new contents of the branch: some content

Now :showContent outputs something different than an empty string:

%Repository:repositoryExample> :showContent 
    Enter version: x
"some content"

This is our current and latest solution - some content. If we want to change it again - :editBranch command is to the rescue. We can change it as many times as we want. But there is a pitfall - it will be our only one current and latest solution. Meaning there is no possibility to track previous solutions (history) and choose between them. Sometimes that’s all we want, especially when things are simple - latest one is the best one, no matter how many times we change our mind about what is best, right?

Tell it to your friend you share your best solution with! I mean, she will have a good point - some content is kind of bleaky and, if fact, does not solve anything. ‘The best solution is the one that works’ she says. Probably you should come up with something else. ‘No problem!’ you say and come up with another one:

%Repository:repositoryExample> :editBranch 
    Enter version of the branch to edit: x 
    Enter new contents of the branch: some different content

%Repository:repositoryExample> :showContent 
    Enter version: x
"some different content"

This is the best solution, you think. But your friend doesn’t share your optimism. No matter how many solutions you show, she will always have a point why it is not the best one. Good friend? Of course! She cares about you to come up with the best solution possible. Actually, is there a better way to go around this? You both want the best possible solution after all… What if you were able to share several solutions simultaneously? That would probably speed things up with the decision making process about what solution works - you show your friend two solutions at once for her to tell you which one to throw away so that you could at least understand faster which one is not the best you’re looking for. In order to share two solutions simultaneously, you need to be able to have two versions of it that exist side by side. Can VersioningRight do that? Of course! But first we need to do something that would let us understand another basic principle - revisions.

Revisions

%Repository:repositoryExample> :toggleRevisions
"repositoryExample" => 
 0 
 | 
 x

As you can see, command :toggleRevisions enables output of another version 0 that is there in the version tree of initial repository. We have nothing to do with it. Seems like it has been sitting there all along, we just didn’t have chance to see it. VersioningRight has been hiding it for the sake of simplicity. We didn’t want to know that there are two solutions. But now we need to know more.

%Repository:repositoryExample> :showContent 
    Enter version: 0
""
%Repository:repositoryExample> :showContent 
    Enter version: x
"some different content"

So, we have two solutions - one empty (which is 0), another non-empty (which is x). The empty one is what we started with, remember? Can we modify this another version 0 that is already there to share another solution with friend?

%Repository:repositoryExample> :editBranch 
    Enter version of the branch to edit: 0
You should enter branch version. Aborting operation

No! It says it is not a branch. What is it then? Ah, it appeared after executing command :toggleRevisions, so it must be revision. What is so special about it that it got another name? We kinda already know the answer. This is because we can’t modify it - :editBranch command didn’t work on it. So, we figured out, there are actually two things in an initial repository - version that you cannot modify (0) and another version that you can modify (x). For that particular reason 0 is called revision and x is called branch. Revisions cannot be modified while branches can. Initial repository is always started with two empty solutions - one editable, another non-editable. We have been playing with the editable one all along. It gave us possibility to come up with something new. Even though is seems useless, you have to admit that there is nothing like the revision 0 - it is an empty solution that both works and doesn’t work at the same time! It works because it kinda always does, no matter what. But you need to come up with your own. In that sense it doesn’t work.

Now that we’ve learned we cannot modify existing revisions, how can we add another one? :newRevision command is to the rescue:

%Repository:repositoryExample> :newRevision
    Enter commit message: some solution
    Enter version, which will be used to append new revision to: x 
"repositoryExample" => 
0
|
x
|
1

What do we see here? It asked us for some commit message! What is the purpose of this? Very simple. It allows us to shortly describe how our solution is better than the previous one. Everything is better than empty solution! Hence the entered value of commit message: ‘some solution’. One more question: “Why is it called commit message, not revision message?” Answer: "Because while revision represents full content of a branch at some specific point, commit represents difference between revisions". Revision 1 is a snapshot of branch x, while commit 1 is a difference between revision 0 and revision 1.

Also :newRevision asked about the ‘version to append new revision to’. It means that revisions are somehow ‘appended’. Does it have something to do with the way versions appear in the version tree? Looks like it does. Judging by the :newRevision command output and its second argument value, 1 has been appended to x. Following this logic, we can say that x has been appended to 0. Hm. Did we do this? Does not seem so. Looks like 0 and x were there as a part of the initial repository. Was it indeed there or did we do something to append x to 0? The answer is yes (0 and x were there as parts of the initial repository) and yes (we did something to append it). How could that be? Simple. Behind the scenes we did repository instantiation. Meaning of this operation is to allow the possibility of coming up with your own solution to the problem. Empty solution 0 is always there for any problem no matter what. And by instantiation of repository we append x to 0 with that allowing to modify empty solution how we please. To understand more, we need to learn about something else - experimental branches.

Experimental branches

%Repository:repositoryExample> :newExperimentalBranch 
    Enter name of the branch to be created: exp1
    Enter version, which will be used to append new experimental branch to: x 
"repositoryExample" => 
     0     
     |     
     x     
     |     
 -----     
/     \    
1     2    
      |    
   x (exp1)

As we can see, appending of the new experimental branch with the name exp1 to the existing branch x resulted in creation of revision 2 that sits between new and old branch. Hm. Weird. Not that weird actually if you look closer to see a pattern. No? Thought so. But it is there, difficult to spot right away though indeed. A hint question - what does initial repository look like?

0
|
x

Now do you see it? Of course you do - structure similar to initial repository was appended to the x branch! There are three subtle differences though. First is that there is 2 instead of 0. Second is that new experimental branch gets displayed not only as its version, but version followed by its name in parentheses. Third is that new branch has the same version as the old branch. Aren’t they supposed to be different? Let’s address those peculiarities slowly one by one.

Sequence, order and history

Remember when we talked about repository instantiation and how x ‘takes’ empty solution 0 to modify it in any way we want? Same happens with instantiation of experimental branches. The difference is that starting point is not the empty solution 0, but some non-empty solution. More specifically, state of branch x becomes a starting point for another branch. Which state? The current/latest one. And how to ‘record’ the state of the branch? By taking a snapshot or, more specifically, instantiating a revision. This is what revision 2 means - it is the snapshot of latest content of the branch x that becomes starting point for content of the branch x (exp1):

%Repository:repositoryExample> :showContent 
    Enter version: x
    Enter branch name to show content: 
"some different content"
%Repository:repositoryExample> :showContent
    Enter version: 2
"some different content"
%Repository:repositoryExample> :showContent 
    Enter version: x
    Enter branch name to show content: exp1 
"some different content"

For the moment contents of x, 2 and x (exp1) are all the same. Can we modify it? Yes, but only contents of branches because, as you might remember, revisions are non-editable:

%Repository:repositoryExample> :editBranch 
    Enter version of the branch to edit: x
    Enter branch name to edit content: 
    Enter new contents of the branch: yet another content
%Repository:repositoryExample> :editBranch 
    Enter version of the branch to edit: 2
You should enter branch version. Aborting operation
%Repository:repositoryExample> :editBranch 
    Enter version of the branch to edit: x
    Enter branch name to edit content: exp1
    Enter new contents of the branch: experimental content

This means now that we have another branch, we can modify two different solutions independently as we please. This is what we wanted when discussed speeding up the process of decision making with the friend, isn’t it? Well, not quite. We didn’t want to work on two solutions in parallel just yet. We wanted to share a solution and be able to continue working on another one being sure that friend will see what we intended her to see. Imagine the opposite - us sharing a solution that keeps changing. In that case, what our friend is supposed to give feedback to?! In other words, all we wanted is to be able to share results of our work that do not change. A snapshot. That’s what revisions are, aren’t they? Let’s keep exploring them:

%Repository:repositoryExample> :newRevision 
    Enter commit message: some another solution
    Enter version, which will be used to append new revision to: x
"repositoryExample" => 
      0       
      |       
      x       
      |       
 ------------ 
/     |      \
1     2      3
      |       
   x (exp1)

Do you remember the situation when current/latest state of branch x became a starting point for another branch? This happened with the help of a revision. When :newRevision command is run, current content of branch (editable entity) is taken/copied to form content of revision (non-editable entity). If there are several revisions instantiated on the same branch, they form an order that allows to talk about the sequence in which snapshots of the branch were taken. Thus, revisions enable history. That’s why numbers represent revisions - they establish order and direction. When revision 2 appeared, it meant that it was instantiated after the previous one, which is 1. And 3 was instantiated after the previous one, which is 2. Sequence, order and history.

Only meaningful history

Let’s look at history of revisions:

%Repository:repositoryExample> :showContent 
    Enter version: 1
"some different content"
%Repository:repositoryExample> :showContent 
    Enter version: 2
"some different content"
%Repository:repositoryExample> :showContent 
    Enter version: 3
"yet another content"

What would be the content of revision 4 if we run :newRevision command now on x branch? Let’s figure it out by running a command:

%Repository:repositoryExample> :newRevision
    Enter commit message: yet another solution
    Enter version, which will be used to append new revision to: x
"repositoryExample" => 
      0       
      |       
      x       
      |       
 ------------ 
/     |      \
1     2      3
      |       
   x (exp1)

It would not create revision 4 for us! Why is that? Because revision 4 in a sense is already there. Where exactly? Let’s look for it:

%Repository:repositoryExample> :showContent 
    Enter version: 0
""
%Repository:repositoryExample> :showContent 
    Enter version: x
    Enter branch name to show content: 
"yet another content"
%Repository:repositoryExample> :showContent
    Enter version: 1
"some different content"
%Repository:repositoryExample> :showContent 
    Enter version: 2
"some different content"
%Repository:repositoryExample> :showContent
    Enter version: 3
"yet another content"
%Repository:repositoryExample> :showContent 
    Enter version: x
    Enter branch name to show content: exp1
"experimental content"

Do you see what is going on here? No? Ok, let’s narrow it down. Do you remember that revision takes a snapshot of latest content of source branch? There is already a revision that corresponds to the latest content of branch x and it is revision 3. Is that the reason why :newRevision command would not create another revision for us? Let’s find out:

%Repository:repositoryExample> :editBranch 
    Enter version of the branch to edit: x
    Enter branch name to edit content: 
    Enter new contents of the branch: one another content
%Repository:repositoryExample> :newRevision
    Enter commit message: one another solution
    Enter version, which will be used to append new revision to: x
"repositoryExample" => 
        0        
        |        
        x        
        |        
 --------------- 
/     |      |  \
1     2      3  4
      |          
   x (exp1)

Whoa! It is there now, brilliant! What is the lesson here? Simple - it makes sense to assign new numbers to the things that are somehow different from previous ones. As long as it is not possible to modify revisions directly, the way to come up with another one is through modification of parent branch.

What about revisions 1 and 2? They have absolutely identical content yet somehow revision 2 was created without any problems. But do you remember how revision 2 was created? Not with :newRevision command, but with :newExperimentalBranch command. The reason why content of revision 2 was allowed to keep the same as 1 is because it was not only about recording the state of the parent branch, but also about event of branch instantiation. So, 2 is different from 1 in a sense that it helped bringing another entity to life that was not there before. Thus, revisions help to track meaningful repository events and the order, in which they happened. Only meaningful history.

Scope

Let’s try to instantiate revision based on experimental branch:

%Repository:repositoryExample> :newRevision exp1 
    Enter commit message: experimental solution
    Enter version, which will be used to append new revision to: x
"repositoryExample" => 
        0        
        |        
        x        
        |        
 --------------- 
/     |      |  \
1     2      3  4
      |          
   x (exp1)      
      |          
      5

Hm. Unexpected outcome. Is it? But what would you expect then instead of 5? a? Would it make sense if we say that revisions are there for recording what happens not only to specific branches, but to the whole repository? Let’s keep exploring. For example, how would the ‘unexpected turn of events’ with 5 appearing ‘out of place’ change the history of x branch if we try to add new revision to it?

%Repository:repositoryExample> :editBranch 
    Enter version of the branch to edit: x
    Enter branch name to edit content: 
    Enter new contents of the branch: one more content
%Repository:repositoryExample> :newRevision 
    Enter commit message: one more solution
    Enter version, which will be used to append new revision to: x
"repositoryExample" => 
         0          
         |          
         x          
         |          
 ------------------ 
/     |      |  |  \
1     2      3  4  6
      |             
   x (exp1)         
      |             
      5

History is broken! Well, not quite. It just means that history is happenning not only at one place, but at different places. Thus, repeating what we already said before: scope of revisions is the whole repository. Meaning that whatever gets recorded in a repository, gets a revision.

What about content of branches then? Isn’t it being recorded as well? Not quite. At least not in a sense of keeping track of every single change that happens to a branch - repository has the latest content of the branches themselves. History of the branch can be figured out based on corresponding revisions appended to the branch. Given that decisions about creating revisions have been made in the past. Decisions about new revisions are decisions about storing progress. Why to store progress? To share it. Why share it? To get feedback. Why to get feedback? To get help on solution. Feedback is the simplest form of getting help or, in other words, collaborate on the solution. That’s right - you and your friend are collaborators working together on the solution. More people are involved in problem solving when there is more than one version of the solution. That brings us to the whole point of versioning - being able to involve other people in problem solving.

This understanding brings us further. What if friend wants to not only give feedback, but also to contribute? That would be another level of collaboration activity - problem solving participation.

Problem solving participation

Being able to independently contribute is, in fact, why we needed the branch in the first place. It’s good to be able to try to solve the problem in two different ways yourself, but it is even better if another person can come up with their own solution independently from us and then share it with us or, even better, make their solution part of ours, for example, by merging. In fact, number of people that can work on the same branch is not limited. In that sense branches are the entities that enable collaboration by participation.

Version is a unique descriptor of the solution in a way that it allows to tell about the type of solution and its place in repository history. Having in mind what we saw so far, we conclude that x represents branches while versions in a form of a number represent revisions. While talking about order of branches does not make a lot of sense so far because of the only branch version we had chance to see (x), numbers of revisions tell us a lot about the order, in which they have been created. Also version of branches x tell a lot about the content, which branch can have. In this specific case of x it can be any content without any restrictions. This is the essence of experimental branches - they can contain anything, thus enabling the most general way of collaboration. In that regard all branches we have seen so far are similar. But they are different at the same time at least because they have different content. And this is how branch name is important. It is used to distinct between branches of the same kind. Hence the name in parentheses after the version: x (exp1). Experimental branch with no name is a special one. It has even got its own name - mainline. This is because it is the branch that gets updated with first possible solution and ultimately ends up with containing the latest solution (ideally, when all other corresponding child branches have been merged back).

Apart from experimental branches that enable collaboration in general, there are also other kinds of collaboration, such as, errors feedback (special case of feedback) and errors fixing (special case of participation). That’s what release branches are for.

Release branches

Let’s run :newReleaseBranch command to see it in action:

%Repository:repositoryExample> :newReleaseBranch 
    Enter version, which will be used to append new release branch to: x
"repositoryExample" => 
                x.0                
                 |                 
                x.x                
                 |                 
  -------------------------------  
 /       |        |    |    |    \ 
x.1     x.2      x.3  x.4  x.6  x.7
         |                       | 
     x.x (exp1)                 0.x
         |                         
        x.5

Wow! This is just… perplexing, to say the least. First, what happened to all the versions? They just ‘doubled’! Is this just a temporary side-effect? May we have old versions back? Second, where is the release branch in all this mess? Did we convert existing branches into a release type or did we add a new one? Third, is this the same history or was it somehow ‘rewritten’? In either case, why? Let’s address those peculiarities slowly one by one.

Bad news first. This is not a temporary side-effect. There is no going back. Once at least one release branch gets instantiated, version tree starts looking like this. But old versions are, in some sense, still there:

%Repository:repositoryExample> :showContent 
    Enter version: x
    Enter branch name to show content: 
"one more content"
%Repository:repositoryExample> :showContent 
    Enter version: x
    Enter branch name to show content: exp1 
"experimental content"

The twist is that all existing versions now have a weird prefix x.:

%Repository:repositoryExample> :showContent
    Enter version: x.0
""
%Repository:repositoryExample> :showContent
    Enter version: x.1
"some different content"
%Repository:repositoryExample> :showContent 
    Enter version: x.2
"some different content"
%Repository:repositoryExample> :showContent 
    Enter version: x.3
"yet another content"
%Repository:repositoryExample> :showContent 
    Enter version: x.4
"one another content"
%Repository:repositoryExample> :showContent 
    Enter version: x.5
"experimental content"
%Repository:repositoryExample> :showContent 
    Enter version: x.6
"one more content"

Now that we’ve made sure everything that was there in the repository didn’t go away (it just has gotten a version ‘extension’), we can spot new entities:

%Repository:repositoryExample> :showContent
    Enter version: x.7
"one more content"
%Repository:repositoryExample> :showContent
    Enter version: 0.x 
"one more content"

Seems like 0.x is our new release branch. Let’s make sure. Can we change it?

%Repository:repositoryExample> :editBranch 
    Enter version of the branch to edit: 0.x 
    Enter new contents of the branch: cntent 4 rellease
%Repository:repositoryExample> :showContent 
    Enter version: 0.x 
"cntent 4 rellease"

We can! Good news, after all, is that 0.x is a branch indeed. Turns out we added a branch, not modified existing ones. Does that mean x.x represents experimental branch now? You bet it does!

%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"

Turns out experimental branches can be referenced both by old x and by new x.x. Is x actually the same as x.x? Yes it is. Oooh, hidden dimension? That’s exactly what is going on here. :newReleaseBranch revealed a hidden dimension that was ‘sitting’ there, we just didn’t see it. Just like we didn’t see revisions before running :toggleRevisions. Let’s run it once again, just for laughs:

%Repository:repositoryExample> :toggleRevisions
"repositoryExample" => 
      x.x      
       |       
     --------  
    /        \ 
x.x (exp1)  0.x

Laughs or no laughs, it looks like it gives us simplified overview that we might use to our advantage. Ok, I want to hear your theory behind brand new release branch version. You say x. is a hidden dimension and 0. is a ‘materialized representation’ of that dimension? WOW! I am amazed! I could not describe it better myself! That explains perfectly why we didn’t need that dimension before running :newReleaseBranch command - we didn’t need release branches. Now that release branch is instantiated, hidden dimension comes to light together with the release branch 0.x itself. The history was not ‘rewritten’, it just got refined a bit.

Let’s go back to the representation where revisions are there:

%Repository:repositoryExample> :toggleRevisions
"repositoryExample" => 
                x.0                
                 |                 
                x.x                
                 |                 
  -------------------------------  
 /       |        |    |    |    \ 
x.1     x.2      x.3  x.4  x.6  x.7
         |                       | 
     x.x (exp1)                 0.x
         |                         
        x.5

Now that we are talking about ‘materialized representation’ of the dimension, we can’t help, but spot another pattern. Looks like revisions are ‘materialized representations’ of experimental branches. Not seeing it? Well, if you look at the right dimension .x instead of left one x., it looks like all the revisions are results of ‘materialized representation’ of the right .x dimension: x.0, x.1, x.2, … But the problem is that x.0 comes ‘before’ x.x in the version tree hierarchy. Meaning x.0 was there earlier than x.x. Fair point. It is worth brining up the memory of the initial repository version tree though:

0
|
x

In that configuration there was no ‘before’ or ‘after’. Two sides (non-editable and editable) of essentially the same empty solution coexisted before the bare notion of direction entered the picture. Thus, it is rather a mystery what comes first - non-extendable void or the void that can be filled. This is a choice to be made. Otherwise the structure and its laws are lean and sound - revisions are instantiated via experimental branches.

If revisions get instantiated by ‘materializing representation’ of the right dimension .x and release branches get instantiated by ‘materializing representation’ of the left dimension x., what happens when both dimensions get ‘materialized’, for example, into solution with version 0.0? That is when release snapshots appear.

Release snapshots

In the spirit of previous adventures, let’s keep exploring by running new things. Command :newReleaseSnapshot in this particular case:

%Repository:repositoryExample> :newReleaseSnapshot 
    Enter version, which will be used to append new release snapshot to: 0.x 
"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   
                                   |    
                                Test/0.0

Well well. There is something unexpected, as always. But we have to admit there is something expected too - 0.0 is featured as advertised. What is so (un)expected about it? Every new step is a combination of expected and unexpected elements. In general, that’s how the problem is getting refined together with the progress towards the working solution. Test/ is a new aspect of both the problem and the solution. This new aspect is called maturity. The aspect that we already know about is called version number. 0.0, x.0, x.1, x.x, 0.x are all version numbers. We called them earlier as versions though, which is also correct. This is because aspect of maturity has been hidden before the introduction of release snapshots. Maturity together with version number form a version. If there is no maturity, just a version number, it is still a version.

Now that there is a deeper analysis of release snapshots going on… We have come across the concept of snapshots before, haven’t we? Remember talking about revisions and how they capture the latest state of a particular branch? We referred to that as ‘taking a snapshot’. Revisions are indeed snapshots. So are particular kinds of snapshots, such as release snapshots. We can’t modify them. Apart from that, there is another special thing about all snapshots - their version numbers end with an actual number. Unlike branches, version numbers of which end with an x. What’s so special about release snapshots specifically as opposed to snapshots in general? They get created only based on release branches. Do you remember what is the purpose of release branches? To collaborate on errors elimination. While release branches are for contributing error fixes, release snapshots are for getting errors feedback. Release snapshots hit broader audience than just contributors to solution. They are targeted at all people that help with finding errors in the solution. In order to be able to tell errors apart from expected behavior, problem has to be defined to the extent that allows to test solution against that problem definition. While having the problem definition is a sign of problem maturity, having a solution to test against that definition is a sign of solution maturity. That’s why release snapshots have maturity as part of their versions. In order to understand more about different release snapshots and their target audiences, we need to learn more about maturity levels.

Maturity levels

We already know that there is at least one maturity level - Test. That’s all we will ever want, right? After all, getting errors feedback is in fact testing. So it makes sense to have Test snapshots as a sign that they are being tested. Can we keep it simple? Let’s fix some errors to get a new release snapshot and see:

%Repository:repositoryExample> :editBranch 
    Enter version of the branch to edit: 0.x 
    Enter new contents of the branch: c0ntent 4 release
%Repository:repositoryExample> :newReleaseSnapshot 
    Enter version, which will be used to append new release snapshot to: 0.x 
"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   
                                   |         |    
                                Test/0.0  Test/0.1

It will be simple as long as we keep it simple. No other maturity levels appeared as a result of :newReleaseSnapshot command. Are we sure that we need to learn about other maturity levels? You can stop at any point if you think you’ve learned enough to meet your needs. That, in fact, was always the case. Many stop after learning that there is a single branch they can use to work on their solution.

I want to learn more