Assessment of Versioning Paradigms with respect to Software Configuration Management

Software still remains a major challenge since 50 years for theoretical and practical work in Software Configu- ration Management (SCM), tracking and controlling changes. This paper provides an overview with classification of different versioning models and paradigms by defining fundamental concepts such as revisions, variants, configura- tions, and changes. It assesses various versioning schemas used in different companies as commercial and open source systems. As a result of this survey, this paper then proposes Github's Semantic Versioning as the most consistent and logical to control versioning.


II. Introduction
Software configuration management is the discipline of tracking and controlling changes in large and complex software systems. SCM practices include revision control and the establishment of baselines. If something goes wrong, SCM can determine what was changed and who changed it. The importance of SCM has been widely recognized, as reflected in particular in the Capability Maturity Model (CMM) [1] developed by the Software Engineering Institute (SEI) [9]. SCM is seen as one of the key elements for CMM. Furthermore, SCM plays an important role in achieving ISO 9000 conformance. SCM can serve both as: · Management support discipline : SCM is concerned with controlling changes to software products such as identification of product components and their versions, change control, status accounting, and audit and review · Development support discipline : SCM provides functions that assist developers in performing coordinated changes to software products. SCM is in charge of accurately recording the composition of versioned software products evolving into many revisions and variants, maintaining consistency between interdependent components, building compiled code and executables from source, and constructing new configurations based on project descriptions.
In this paper, we will consider SCM as a development support discipline.

III. LITERATURE REVIEW
In software engineering, software configuration management (SCM) is the task of tracking and controlling changes in the software, part of the larger cross-discipline field of configuration management [8]. The major goals of SCM are: · Version and Configuration control · Configuration identification · Build management · Configuration status accounting · Defect tracking · Environment management · Process management · Configuration auditing · Team interactions and teamwork This paper primarily focuses on overview and classification of different versioning paradigms and proposes SemVer as the consistent and logical versioning scheme.

Figure-1: Taxonomy of software versioning [3]
A version model defines the objects to be versioned, version identification and organization, as well as operations for retrieving existing versions and constructing new versions. Software objects and their relationships constitute the product space, their versions are organized in the version space. A versioned object base combines product and version space [16].
Many SCM systems use version graphs for representing version spaces. A version graph consists of nodes and edges corresponding to (groups of) versions and their relationships, respectively.
SCM system is illustrated in Figure, where versioned objects, revisions, and variants are organized into orthogonal dimensions: Several SCM systems are founded on databases and manage versions of objects and relationships stored in the database. Graphs are well suited to represent the organization of a versioned object base, even if the corresponding system is not graph-based. For example, SCCS and RCS are both file-based, but the version space of a text file may be represented naturally as a version graph [10].
To represent versions in the object base, deltas are being used both at the coarse-grained and the fine-grained levels.
Deltas are mainstay in Version Control Systems and are calculated using some data differencing algorithms/programs (for e.g. diff utility [18]). Formally, a data differencing algorithm [17] takes as input source data and target data, and produces difference data such that given the source data and the difference data, one can reconstruct the target data.  2. Two-way merging: This compares two alternative versions a1 and a2 and merges them into a single version m. This can only detect differences, and cannot resolve them automatically.

Figure-3(b): 2-way versioning [3]
3. Three-way merging: This consults a common baseline b if a difference is detected. If a change has been applied in only one version, this change is incorporated automatically. Otherwise, a conflict is detected that can be resolved either manually or automatically. Figure-3

IV. Need Of Logical And Consistent Versioning
Enterprise software is designed to take advantage of other software components that are already available (rather than reinventing the wheel), or have already been designed and implemented for use elsewhere. Dependency hell [5] (also known as DLL hell on Windows, Extension Conflict on Mac OS, JAR hell in Java and RPM hell on Red Hat Linux based systems), in which installed packages have dependencies on specific versions of other software packages, is a major frustration of software users. The dependency issues arise around shared packages/libraries on which several other packages have dependencies but where they depend on different and incompatible versions of the shared packages.
If the shared package/library can only be installed in a single version, the user/administrator may need to address the problem by obtaining newer/older versions of the dependent packages. This, in turn, may break other dependencies and push the problem to another set of packages.
As a responsible developer you will, of course, want to verify that any package upgrades function as advertised. The most obvious (and easiest, though often ignored) solution to this problem is to have a strict, standardized, logical and consistent version numbering system. This is not a novel or revolutionary idea. In fact, most developers and software companies do something close to this already (as outlined in previous section). The problem is that "close" isn't good enough. Without compliance to some sort of formal specification, version numbers are essentially useless for dependency management. What you can do is let Semantic Versioning provide you with a sane way to release and upgrade packages without having to roll new versions of dependent package saving manpower, time and effort. According to this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next (so that developers can handle the problem of dependency hell).

V. Semantic Versioning
In Semantic Versioning, the developer first declares a clear and precise public API (which either may consist of documentation or be enforced by the code itself). Once the public API is identified, the developer communicates changes to it with specific increments to the version number. As an example, consider a version format of X.Y.Z (X = Major, Y = Minor and Z = Patch). Bug fixes not affecting the API increment the patch version (Z), backwards compatible API additions/changes increment the minor version (Y), and backwards incompatible API changes increment the major version (X). A detailed secification of Semantic Versioning is available at http://semver.org/. To be able to use SemVer, developers or company needs to declare that they are doing so (by linking to SemVer website/specification from project's documentation so that others know the rules and can benefit from them) and then strictly and consistently follow the SemVer rules.

VI. Conclusion
Even though developers and software companies use different versioning schemes, industry needs to agree on a consistent, logical and strict versioning scheme as a solution to the dependency hell problem. One strong candidate is Sem-Ver which is clear, consistent and concise and is being used (with minor variations) by many companies and developers.