How to use the M2 lifecycle

As your metamodel evolves, Farkitect provides lifecycle features to help manage the impact of changes on existing M1 models.

Track usage

Select an M2 metamodel’s root package. The Properties panel shows:

Imported by Packages — the M1 models that import it (click one to select it), plus how many elements, diagrams, catalogs and boards depend on it. “No M1 models use this metamodel.” when nothing does.
Version — the metamodel’s version, and its latest upgrade: who ran it, when, how many types were retired, held back, mapped or deleted, and the name of the backup file. If the last upgrade didn’t complete, it says so and tells you how to finish it.

This helps you understand the impact of changes before making them.

Deleting M2 types

Deleting an M2 type (or a whole metamodel) that models use is not blocked. The model data that uses it is deleted with it.

The delete confirmation tells you what’s at stake:

N elements will be deleted. — the item itself and everything inside it
A red warning when models use it: “This will also permanently delete N model elements, N relationships and N property values that use it across your models.”
Export a backup of the project first — tick this to save a .farki of the whole project before anything is deleted

Deleting an M2 package always runs in the background: its row in the Explorer shows dimmed as Deleting…, and a progress toast counts through the work. Large M1 deletes run the same way.

To remove types without losing model data, don’t delete them. Upgrade the metamodel to a version without them: types that models still use are retired — kept for existing elements, no longer offered for new ones. Later, Resolve Retired Types… lets you map those elements to other types or delete them deliberately.

Renaming M2 types

Renaming an M2 element type is safe — M1 instances reference the M2 type by ID, not by name. The rename propagates immediately:

The Palette shows the new name
M1 elements show the updated classifier name in the Properties panel
Diagrams re-render with the updated stereotype label
Exports use the new name

Modifying M2 properties

You can add, remove, or modify properties on an M2 type at any time:

Adding a property — all existing M1 instances gain the new field (initially empty or with the default value)
Removing a property — deleting it also deletes its values on every M1 instance; the delete confirmation counts them. To keep the values, upgrade the metamodel instead, which retires a property that elements still use
Changing a property type — existing values may become invalid; the integrity checker flags type mismatches

Modifying constraints

Changing relationship constraints affects future relationship creation but does not retroactively invalidate existing relationships. The integrity checker can detect M1 relationships that violate updated constraints.

Moving a model to a different metamodel

Everything above is about changing a metamodel in place. There are two ways to bring a new version to your models:

The same metamodel, newer version — upgrade it from the new .farki. Every element keeps its id and diagrams, and you decide what happens to removed types.
A different metamodel that sits beside the old one — migrate the model. Types are matched by name, with a preview before anything changes.

Retired types

A metamodel type, property or enumeration value that an upgrade removed but models still use is retired. It stays in the metamodel so nothing breaks, but it is no longer offered:

Retired types are hidden from the Palette, the New Element type list and relationship pickers
A retired enumeration value is hidden from value pickers; it shows marked (retired) only while it is an element’s current value
A retired property is hidden in Properties; it shows labelled (retired) only where the element has a value

Where retired items still appear, they’re marked:

Explorer — a muted retired label next to retired definitions and elements of a retired type
Diagrams — nodes of a retired type carry a small retired chip and are dimmed. Relationships touching them are not dimmed unless the relationship’s own type is retired
Properties — a banner: “<Type> was retired in version X: it is kept for existing elements like this one but no longer offered for new ones.”

To find them all, click the archive icon in the Explorer toolbar, Show only retired (N). It appears only when something is retired.

See How to upgrade a metamodel and Resolve retired types later.

Compliance warnings

An M1 element is dimmed — in the Explorer and on diagrams — and its Properties panel shows a warning banner when it no longer fits its metamodel:

Case	Banner
Its metamodel isn’t imported by its package	This element’s metamodel is not imported by its containing package.
Its type was deleted	This element’s type no longer exists in the metamodel.
A relationship breaks its type’s constraints	This relationship’s source→target pair is no longer valid per its type’s constraints.
It uses a retired type	<Type> was retired in version X: …

The first three are problems to fix. A retired type is not — the element is still valid, just no longer something you can create.

Best practices

Make M2 changes during quiet periods when collaborators aren’t actively modelling
Use the integrity checker after M2 changes to identify any M1 inconsistencies
Consider marking mature M2 metamodels as read-only to prevent accidental modification
Export your M2 as a .farki backup before making significant structural changes