Skip to content

Versioning

Every module has a version assigned to it. A version comprises a number and a status. The version number is a positive integer value. There are four possible values for the status:

Status  
SNAPSHOT The elements in the module can be modified and moved to different modules. Element creation and deletion is allowed.
RELEASE The elements in the module can neither be modified nor moved to a different module. Elements can neither be created nor deleted in the module. You can think of a RELEASE module as a module that is sealed.
DEPRECATED This status has the same meaning as RELEASE. Additionally, it indicates to the user that in the not so distant future, the module is going to be archived.
ARCHIVED This is the terminal state of a module. Archived modules and their elements will not show up in any search results.

No Version Number for Elements

Elements don’t have a version number or a version status. It is always the module that has this. Otherwise it would become impossible for a human being to manage all dependencies between Elements in combination with the management of version numbers and the version status. Imagine you have for instance 50 model elements of type “Entity” (DSL “Persistence”) and want to increment their version number. You wouldn’t want to increment the version number 50 times, one after the other.

Version Numbers

The web modeler doesn’t apply semantic versioning but a much simpler approach. A version number is simply a positive integer value. That number alone doesn’t tell you anything about the status of the module content. And you cannot set this version explicitly. Changing a module status from SNAPSHOT to RELEASED automatically increases the version number. See Releasing a Module for details on the process of version increments.

Rules for Status

  • The lifecycle of a module status is straightforward:
    SNAPSHOT ↔ RELEASE → DEPRECATED → ARCHIVED
  • Elements of a module with the status SNAPSHOT can be linked to elements that are part of modules with status SNAPSHOT, RELEASE or DEPRECATED.
  • The latest version of a set of module versions always has the status SNAPSHOT.
  • The status of a module that has the status RELEASE can be set back to SNAPSHOT to be able to make changes to the module.
  • Switching the status of the latest version of a module to RELEASED automatically creates a new SNAPSHOT version, which holds copies of the original elements and their options and links.

Warning

Be careful when you change the status of a module from RELEASE to SNAPSHOT. Code that got generated for a module with status RELEASE normally itself has been released already. Only insignificant changes should be made in such modules. Also: Setting the stauts back to RELEASE afterwards, will not create another, newer version since there is already a newer version of the module.

Rules for Module Dependencies

  • A module must not have a dependency to two different versions of the same module.
  • More than one version of a module can have a dependency to the same version of a different module.
  • It is possible that two modules have a bidirectional dependency.
  • Any module dependency graph must not include two versions of the same module.

Releasing a Module

As has been said before, switching the module status for the latest version to RELEASED creates a copy of the module, whith an increased version number and an initial stauts of SNAPSHOT. But what happens to the links of the elements in the original module?

This is what is happening:

  • When a module version is increased, copies of outgoing links are going to be created. The new links point to exactly the same elements as the original ones.
  • When a module M1 has a dependency to the version N of a different module M2 and that dependency is going to be changed to point to the version N+1 of that module M2, the following happens: All links from M1 to M2(N) are changed by replacing the target element of the links with elements of M2(N+1). If M2(N+1) doesn’t have a target element for a given link, since the element has been removed, then the existing link is simply going to be removed.

Moving an Element to a different Module

When you move an element to a different module, you create a new dependency between modules and possibly remove an existing dependency between modules. According to the rules for the module status, you can only move an element from a SNAPSHOT module to a another SNAPSHOT module. If the movement of an element violated the rules for module dependencies, the movement wouldn’t complete successfully. So you don’t have the chance to make a mistake here.