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 another 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.
Every new Knowledge Base has a default development version. Opening the Knowledge Base Versions tool window (going to Toolbar>View>Versions) 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
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 will go 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
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").
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.
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.
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.).
The current version is displayed in the Preferences and the KB Explorer as shown in the following image.
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:
If you want to |
GeneXus X |
Prior GeneXus versions |
Create a copy of your application at a given milestone. For example, at release time |
Freeze a version |
Copy Knowledge Base directory to a new one |
Continue development for the next version |
Set the default development version as active |
Open the development Knowledge Base |
Fix a released application |
Create a (development) Version from the corresponding Frozen one and set it as active |
Copy the previous backup directory to a new one |
Make a new, separate fix, for released application |
Create another (development) Version from the corresponding Frozen one and set it as active |
Copy the previous backup directory to a new one |
Version Properties
Version Management and Work Methodology with GeneXus Server