Definitions

In Changelogic we call changes objects that bind together tasks and real changes to source code – the differences. While task was a description why and how to implement something, change is realization of that on code base.

In terms of version control, every change is separate branch, which is isolated from other branches and most importantly, from the main branch until it is reviewed for correctness and integrated. You can't propagate unverified code.

Changes are separate objects because they have different life cycle – changes are developed, reviewed and integrated.

A checkpoint is a fixed state of code. Unlike version, which is a fixed state of some mainline, a checkpoint is a fixed state of code of a change branch.

A conflict occurs when the same or adjacent lines of a file have been edited, added and/or removed in several concurrent changes and the lines are then asked to be merged together. For binary files, conflict occurs when a new revision of the file has been checked in in multiple concurrent changes.

A set of development efforts performed to achieve a common goal. For a functionality stage, the common goal is the required functionality; for a production release cycle, the common goal is production release; for a test release cycle, the common goal is test release.

The term forward integration means integrating every change to all newer release cycles which already have a version. The first version to test release cycle is created, when the first change that is planned to current cycle, is integrated. Thus integrating a change to the test release cycle will open it to integrations of changes planned to earlier test release cycles.

It is the procedure of estimating the scope and magnitude of the change.

Integration is the step of when a completed and reviewed change is merged into mainline. The integration is intended to help ensure that the change still works after leaving developer's environment and together with other changes that have been integrated since isolating the change.

Whenever a change is integrated, at least one version is formed (except in case of microchanges, which form checkpoints instead). Multiple versions will be formed for changes planned into earlier test release cycles – one per every test release cycle the change was integrated into.

A microchange is a change that is a part of another change, containing a subset of edits required to complete the larger change. The larger change is then called macrochange of the given microchange.

The purpose of verification is to validate the outcome against goals set in task before implementation. It is usually most effective for the person who entered the task in first place to validate its correctness.

Approval is the phase in task's life cycle where we specify it to the level it is needed to implement this task. So we can say that if approval is done, we have specified every possible detail and answered every possible question of developer who will implement this task.

Production release is the ultimate goal of almost any software development effort. Going to production use marks the era when the product will start to earn back its development costs.

By the term supporting production we mean – releasing an emergency fix for critical bug and doing planned maintenance releases.

The point of vital importance here is that you must be able to support production independently from other ongoing development efforts; you might even run into a situation where you are testing a planned maintenance release but have to issue a critical bugfix independently from the maintenance release.

A directory tree or collection of directory trees of source files that are built into a release unit – a package or set of packages that are released together.

Every single request, requirement, problem, idea and bug coming from clients, analysts or testers is separate task on Changelogic. By definition, a task is a description of why and what you need to accomplish (while change is the realization). We call it a task, because developers can implement it and spend time on that implementation.

The life cycle of a task consists of approval, implementation and verification.

A test release is a version that gets deployed into a test environment – an environment that is not in use for production nor development. The test environment may or may not be public. Deploying a version into test environment before releasing it to production use allows release managers to sweep out bugs related to upgrading the product and provides testers a semi-stable installation they may safely trash around in.

A testcase is a set of inputs to the application and description how the application should behave under these circumstances. Testcases are usually derived from requirements, but they can also be extracted from existing bug reports to ensure the application does not regress. What makes testcases different is the possibility to enter testcase runs – assuring the functionality described in testcase really works in a certain version ofthe product.

A single execution of a testcase. The execution can either fail (behaviour does not match expectations set in testcase), pass (behaviour matches expectations) or turn out to be impossible (inputs described in testcase cannot be applied or behaviour cannot be observed).

Version Control System, a generic name for software systems designed for managing and administrating multiple versions of files or objects. For instance, CVS, Subversion and Visual SourceSafe are among the most known VCSs.

In contrary to a change which can develop in time, a version is a fixed state of code. In terms of source control, a version is denoted by a tag, while a change is a branch. Each version is a result of merging a change on top of preceding version.