In the VisionAppster platform, components are installable software
modules. They serve about the same function as “packages” in a package
manager such as
Builder lets one to create components out of apps
or manually crafted directory structures. There is also a command-line
tool for building packages. Components can be installed
locally and distributed through the VisionAppster
Components can depend on each other. A typical case is an app component that depends on a tool plugin component. To ease managing dependencies, a component package can contain more than one component including their licenses, making the package self-contained.
Each component has a component ID whose uniqueness is ensured by a
convention: each seller chooses a namespace that is usually a reversed
domain name such as
com.visionappster. Within this namespace, the
seller can easily ensure uniqueness of component names.
Component IDs can only contain lowercase letters (a-z) and digits (0-9).
Dots (.) are used as part separators and must be surrounded by at least
one valid name character on both sides. A component ID can be, for
com.visionappster.mvp. The minimum number of parts in a
component ID is two.
It is important to understand that this is just a naming convention; no
one checks that there is a domain that matches the namespace nor that it
is owned by the owner of the component. The VisionAppster Cloud however
ensures the uniqueness of component IDs when new components are
registered. There is one exception to this rule: component IDs starting
system. are reserved for internal use.
Different versions of the same component are identified by a semantic version number. To ensure interoperability of components, the platforms follows the semantic versioning spec very carefully, and so must component owners.
A semantic version number has three parts:
major.minor.patch. If a
change in the component breaks existing functionality, the major version
number must be incremented. Features can be added but not removed when
changing the minor version number. If a release does not add new
functionality but just improves or fixes the implementation, patch must
be incremented. Version numbering can be started at any number, but
usually 1.0.0 marks the first release. 0.0.0 is not allowed.
The most important rule component owners must follow is that all revisions within a major version must be backwards compatible. This makes it possible to upgrade depending components independently. Component licenses also apply to a major version.
Full component ID🔗
Multiple major versions of the same component can coexist. Therefore,
the platform uses a full component ID to identify components. The full
component ID is formed by concatenating the ID and major version number
of a component, e.g.
Components can depend on external software packages such as Python
modules in the Python package index (PyPI). Such packages are
distinguished by a scheme at the beginning of the component id. For
example, practically all components containing Python code depend on
NumPy. The name of the NumPy package in PyPI is
numpy and the scheme
for Python packages is
python. The component ID for NumPy thus
VisionAppster cannot enforce semantic versioning requirements to
external dependencies nor make sure multiple versions of them will work
simultaneously. Python is especially notorious with its virtual
environments. Therefore, only one version of an external dependency can
be installed and versioned (full) component IDs do not apply to them. In
python:numpy always refers to the currently installed
version of NumPy, independent of its version number.
UUID and name🔗
In addition to the component ID, each component distributed through the VisionAppster Store has a UUID that is generated by the cloud service when a new component is registered. The UUID is used on the store side as an immutable identifier for the component for things like billing whereas the more readable component ID is used as the developer-facing unique identifier. Each component in the Store also has a unique human-readable name.
Neither the UUID nor the name are required if a component is built for local use only. They are assigned to a component when it is registered in the Store.