In the VisionAppster platform, components are installable software modules. They serve about the same function as "packages" in a package manager such as
yum. The 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 Store.
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 example
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 with
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.
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.
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.