An application life cycle has several milestones called Versions in GeneXus. A Version holds the status of an application at any given time. It may be a read-only version holding a "photo" of the application at any important time during development. Common names for read-only versions are: Sent to QA, Version 1.0 final, Version 2 as installed in customer X. Versions may also represent separate development threads, sample version names in this case may be, for example: Fixes to QA version, Upgrades to Version 1.0 final,  Hot fixes to Version 2 as installed in customer X.

Having versions of an application in a Knowledge Base targets the following scenarios:

• Separating development threads.

Being able to continue application development while fixing other version(s) without disrupting each other.

• Analyzing changes between application versions

Easily comparing versions, moving changes from one to another, etc.

• Restoring to a previously known state

Versions can be used to make a backup of your applications before making "what if" changes.

• Basic application customization

Even though versions are not the ideal method for customization, they can be used for this purpose in some situations.

A typical development process

Every new Knowledge Base has a default development version. Opening the Knowledge Base Versions tool window shows this default version, which has the name of the Knowledge Base. Development starts on this version, and it continues until you decide that the desired level of functionality and stability has been reached, and it's time to release your work to customers.

At release time, it is a good idea to make a copy of your application as it is released. This is called "Freezing" a version and the result is a Frozen version. Right clicking on the default version node shows the Freeze option. Selecting the Freeze option prompts you for the name and description that will be assigned to the new Frozen version. Default values are good enough at this time, so let GeneXus create your new Frozen version, "Version 1".

Having created a frozen version, you can switch between them (right click on any of them and set it to Active) and perform the following actions:

• Continue application development on the next release
• See exactly what was released as of "Version 1"
• Compare both versions

Fixing the "Version 1" version

The "Version 1" version is a Frozen version. It cannot be changed. If you need to fix it, you must create a new version. Right click on "Version 1" and select the New Version option. Leave the default names and description and create the new version. The new version "Upgrades for Version 1" is an exact copy of what was released on "Version 1".

Now the diagram shows three versions, one of them is Frozen. Set the "Upgrades for Version 1" to active (Set as Active on context menu). From then on, any change you make in objects, or any objects created or removed willgo to "Upgrades for Version 1". Other versions will not be affected.

When you've made all the fixes to "Upgrades for Version 1", it's time to release. Once again, select the Freeze option on "Upgrades for Version 1" in the context menu. Leave the default names for the new Frozen version.

At this time you are able to:

• Continue application development on the next release
• See exactly what was released as of "Version 1"
• Regenerate the application as of "Version 1"
• Continue adding fixes to "Version 1" (changing "Upgrades to Version 1")
• See exactly what was released as of "Version 1.1" (fixes for "Version 1")
• Regenerate the application as of "Version 1.1"
• Compare any versions

Various fix sets for "Version 1" version

While not desirable, sometimes it is necessary to create a separate development thread just to make specific fixes. The most common example is having two customers experiencing different problems. When the first problem arises, you create the "Upgrades for Version 1" version and fix it as described above. Later, the second problem arises in a different customer. This customer accepts the fix to his or her problem, and nothing but that fix (i.e. you cannot fix the problem in "Upgrades for Version 1" as it already has another fix). The solution to this is to create a new version from "Version 1" (select New Version from the "Version 1" context menu) and fix the new problem in this version.

Note the horizontal line starting on "Version 1" and linked to "Upgrades for Version 1" and "Upgrades 2 for Version 1"). It states that both versions share a common starting point ("Version 1").

Continue application development

After an application is released, work usually begins on a new version. The most common tasks are adding new features, making major changes, and introducing fixes to existing versions. The new version is not started from scratch, so: where are these changes made? In what version? They are made in the default development version, the one at the top (root) of the Knowledge Base Versions Diagram.

The development cycle continues until your application is ready to be released again. To create a new Frozen version, select the Freeze context menu option of the root node and leave the default names.

By now you should've already realized how the cycle works: develop -> freeze -> develop -> freeze ... This cycle applies to any Development Version.

Reading the Knowledge Base Versions Diagram

The Knowledge Base Versions Diagram shows the version hierarchy. Each vertical line is a timeline representing a development thread. Earlier versions in each thread are closer to the top of each vertical line. A horizontal line connects versions sharing a common parent Frozen version.

Frozen versions are displayed as light-brown filled rectangles connected to a vertical line. At the top of this line there is always a Development Version.

Development versions are displayed as rounded rectangles connected to one Frozen version. Many Development versions can be connected to a single Frozen one meaning they all share a common source base.

Version naming convention

Versions can have any name you choose, as long as they are not duplicated. Usually, Frozen version have numbers (1, 2, 3, 1.1, 3.2, etc.) and Development ones are named (code name like Yi, Rocha, Solis, etc.).

Frequently Asked Questions

How do I know what version I'm working on?

The current version is displayed in the Preferences and in the Folder View tool windows as shown in the following image.

Comparison with previous GeneXus versions

This section is for GeneXus users that are used to working on versions prior to GeneXus X. The concept of Knowledge Base is a bit different in this version.

Each GeneXus X Version should be considered a Knowledge Base in prior GeneXus versions. A GeneXus X Knowledge Base is, therefore, a set of Knowledge Bases of prior GeneXus versions. A couple of examples may help you understand the concept:

See Also

Version Properties