1.1 Version String Anatomy

Prev		Next

The version string of a group, package, or component can be a rather complex string of characters to read, but it contains a lot of useful information such as the current branch on which the item resides, parent branches from which it was shadowed, and revision information for its source and build.

The full version string begins with a slash (/) and ends with a revision number. The following shows the full version string used to identify a particular revision of group-example (the single line is wrapped):

group-example=/example.rpath.org@corp:example-1-devel//
example.rpath.org@corp:example-1-test//example.rpath.org@corp:example-1//1.0-2-1

Parts of the version string can be used to identify the component, package, or group in certain scenarios where the full version string is more information than you need. For example, in the previous example, you could say that this is revision "1.0-2-1" or that it resides on the label "example.rpath.com@corp:example". However, the full version string ensures that Conary does not try to fill in any missing parts with values relative to your current environment.

To see the full version string of a component, package, or group, use --full-versions with the conary query and conary repquery commands:

$> conary q timescript --full-versions
timescript=/example.rpath.org@corp:devel/1.0-2-1
$> conary rq timescript=example.rpath.org@corp:devel --full-versions
timescript=/example.rpath.org@corp:devel/1.0-2-1

The version string "anatomy" includes the parts shown in this image and described in the following sections:

Figure 1.1. Simple version string with one label (no parent branches)

1.1.1 Branch

A Conary branch identifies a development path. The branch is written with a preceding slash (/) and includes the labels on which the branch resides:

/example.rpath.org@corp:example-1-devel

If the branch has multiple labels separated by double slashes (//), each subsequent label is a child of the previous label. This structure is created when you shadow one package or group to another label (see Section 1.1.4, “Branching with Shadows and Clones”):

/example.rpath.org@corp:example-1-devel//example.rpath.org@corp:example-1-qa//example.rpath.org@corp:example-1

Conary often abbreviates the branch when displaying version strings, leaving out the common (repeated) information between parent and child labels:

/example.rpath.org@corp:example-1-devel//example-1-qa//example-1

Even though this part of the version string is called the "branch," the term "branch name" mentioned in the next section to refers to part of the label helping to identify the branch of development on which the particular package or group resides.

1.1.2 Label

The label portion of the version string is made up of two parts separated by the "at" symbol (@), with the second part further divided by a colon (:). Besides its name, a package's or group's most-often-used piece of information is the label on which it is said to reside:

example.rpath.org@corp:example-1-devel

The parts of the label are as follows:

Repository hostname -- the hostname associated with the Conary repository, though not always resolvable as a DNS hostname; includes the unique name (or "short name") associated with your repository in rBuilder
Branch name -- identifies the development branch among others in the same repository, including two colon-separated parts:
- Namespace -- identifies a corporation, derivative distribution group, or individual who manages the repository in rBuilder (default on rBuilder Online is "rpl")
- Tag -- identifies a development version and stage, and usually repeats the unique name (short name) associated with your repository in rBuilder

When the branch includes multiple labels, the component, package, or group is said to reside on the last label in the series:

/example.rpath.org@corp:example-1-devel//example.rpath.org@corp:example-1-qa//example.rpath.org@corp:example-1

When determining the label on which something resides when it is shown abbreviated, use the common information from the parent branches shown to complete the unknown parts:

/example.rpath.org@corp:example-1-devel//example-1-qa//example-1   <-- only the tag is shown when abbreviated
/example.rpath.org@corp:example-1-devel//example.rpath.org@corp:example-1-qa//example.rpath.org@corp:example-1

1.1.3 Revision

A Conary revision contains values that help determine which component, package, or groups is newer than another with the same name:

3.4a-2-1

A revision includes the following parts:

Upstream version -- arbitrary value assigned by the "version" variable in a package or group recipeConary does not see version 1.2 as higher or lower than 1.1, only compares 1.1 and 1.2 to determine they are different
```
3.4a-2-1
```
Newest application code does not equal newest revision

Conary does not see version 1.2 as higher or lower than 1.1, it only compares 1.1 and 1.2 to determine whether they are alike. No matter which upstream version has the latest application code, Conary considers the "newest" package or group to be the latest one committed to the repository.
Source count -- incremented value that starts at "1" with the first time the recipe and other source code is saved (commited) to the repository; incremented by one on each new commit
```
3.4a-2-1
```
What do decimals mean in the source count?

If the source count has a decimal, this indicates shadowing (see the next section). Each number before a decimal indicates the source count on the parent branch during the last merge from its parent branch. The number after the decimal is the source count of the current package or group.
Build count -- incremented value that starts at "1" with the first build of a package or group source; incremented by one each time the same committed source is built
```
3.4a-2-1
```
Why is a build count missing?

If you are reading a version string and notice a missing build count in the revision, this refers to the source component used to build the package or group.

1.1.4 Branching with Shadows and Clones

Developers use shadowing and cloning to create new development branches of the same packages and groups. This section describes how to read shadow and clone information in your version string. To reference how to create and use clones and shadows, and how to merge changes from parent branches, see Copying and Customizing Existing Conary Packages.

A full version string of a shadow (or clone of a shadow) has two distinguishing features:

The branch includes two or more labels separated by double slashes
The source count includes two or more numbers separated by decimals

Conary appends the parent branch with the shadow's label to create the branch of the shadow. The following are the branches of a parent trove, its shadow, and the shadow of a shadow:

/example.rpath.com@corp:example-1-devel
/example.rpath.com@corp:example-1-devel//example.rpath.com@corp:example-1-qa
/example.rpath.com@corp:example-1-devel//example.rpath.com@corp:example-1-qa//example.rpath.com@corp:example-1

As previously mentioned, Conary often abbreviates the branch of a shadow when it shows it in query results. The "@" and ":" in the label are Conary's abbreviation points. The following shows the same two branches, with one abbreviated to remove the parts of the child label that are the same as the parent label:

/example.rpath.com@corp:example-1-devel
/example.rpath.com@corp:example-1-devel//example.rpath.com@corp:example-1-qa
/example.rpath.com@corp:example-1-devel//example-1-qa

Cloning in Conary creates a sibling relationship between the original trove and its clone, Conary replaces the original trove's label with the sibling's label to create the branch of the clone. When cloning a shadow, this results in two branches that shadow the same parent. The following shows a parent trove, its shadow, and a sibling (clone) of the shadow:

/example.rpath.com@corp:example-1devel
/example.rpath.com@corp:example-1-devel//example.rpath.com@corp:example-1-qa
/example.rpath.com@corp:example-1-devel//example.rpath.com@corp:example-1