What is the use of component versioning for core components and is this needed for project which is being developed aem
Answers
USES OF COMPONENT VERSIONING
Versioning tracked components in a repository helps create a higher-level contracts, for the safe reuse of components between different repositories and users.
Versioning components is essential when collaborating on components to avoid breaking the different applications the components are sourced to or used in. Component versioning can get complex in complex dependency graphs and Bit does a lot to make this process as easy and efficient as possible.
Once a Bit component is tracked, you can version it using the bit tag command.
Upon tagging, Bit will apply the actions below to make sure that the component dependency graph is resolved. It will also validate that the component is isolated and can be reused outside of the repository’s context.
ABOUT COMPONENT VERSIONING
The current release of the Core Components is 2.2.2 and is compatible with AEM 6.3 and up. It was released in October 2018 as an important update to release 2.0.0. Release 2.0.0 introduced new components along with v2 updates of existing components.
See the section Release History and Compatibility of this document for more information.
Versions and Releases
Core Components are distributed via GitHub. This allows Adobe to more quickly add functionality to the components and also allow for community input outside of the AEM release cycle.
The Core Components are made available with defined AEM versions with which they are compatible. This means that one AEM version may support multiple versions or releases of the Core Components. This gives more flexibility than the former Foundation Components, which were tied to a specific version of AEM.
Versions
The major iteration of the Core Components are the versions. Each component has a version. Versions are denoted with v appended with a nonzero, positive integer such as v1 and v2. Versions are incremented only for changes that are not backward-compatible, which is normally the case for the introduction of new features and functionality.
Developers and administrators can recognize versions of the core components by a number in their resource type paths, and in the fully qualified Java class names of their implementations. This version number represents a major version as defined by semantic versioning guidelines.
For more details about core component versions, see the developer documentation of the Core Components.
Releases
The core components are made available through releases and represent the actual published artifacts available on GitHub. Releases are denoted with a decimal number of the format X.Y.Z and collect all core components together as a deliverable package.
Major releases can introduce new versions of existing components along with entirely new components as well as standard bug fixes. This is represented by an increment in the X component of the release number.
Important releases can introduce new functionality to existing versions of components along with bug fixes. This is represented by an increment in the Y component of the release number.
Minor releases contain only bug fixes. This is represented by an increment in the Z component of the release number.