- Brahim Jaouane
- January 19, 2011
Understanding eXo Versioning Scheme
Each software package that eXo releases is flagged with a release number. This identifier follows a nomenclature elaborated to match our software release process. This post will help you to decipher these quite obscure numbers and hopefully better understand how we release our software.
This numbering system applies to our enterprise product offering, eXo Platform (as well as our previous offering, called eXo All-In-One). It also applies to our community project packages, eXo WCM, eXo Collaboration, eXo Knowledge and eXo Social, and even to our lower level software libraries.
Content
Release numbers are composed of several version digits and an optional qualifier, following this pattern X.Y.Z[.P][-Q].
Let’s start with a full (fictive) example:
The major version digit represents the main generation of the software. We increment this version number for each major change in the product architecture.
The minor version digit is incremented when we augment the software with a new set of new features.
The maintenance version digit is incremented when we want to release batches of bugfixes and improvements. The first maintenance version number is always 0.
The patch version digit is optional and hopefully rarely seen. We issue a patch release when an annoying issue, such as a security one, can’t wait for the next release.
Finally, a qualifier may be appended to mark a special brew of the release, usually depicting a quality-level:
- Alpha: alpha versions are made to mark milestones. Not all alpha versions are released publicly and they have usually very little QA. They are often developer releases. An alpha version is issued before the actual release, meaning that 1.0.0-Alpha01 will be a preview of a future 1.0.0-GA version.
- Beta: beta versions are considered feature-complete, and have passed a minimal level of QA tests. Several betas may be issued as feedback is received from the developer community, and as the QA program progresses.
- CR: CR stands for Candidate Release. As the name says, these versions are candidates for an upcoming release. A CR may have some outstanding known bugs, but nothing bad enough to block the release. Several CRs may be released until we are satisfied with the quality of the release.
- GA: GA stands for General Availability. This qualifier is used to mark the software as ready for production. Usually, the first minor version is explicitly marked as GA (e.g 2.1.0-GA) but the qualifier is omitted for subsequent maintenance releases (maintenance releases are production-ready by nature).
- CP: CP stands for Custom Patch. This is used for special versions that diverge from the usual release. Occasionally we are required to provide a release specifically for a certain use case scenario. For example, eXo WCM 2.0.1 needed a JCR 1.12.2-CP01 in order to be deployed specifically on JBoss Enterprise Portal Platform (JBoss EPP).
The list of qualifiers is not restricted to the above. Under special circumstances, we may use others. For example, since eXo products have a different lifecycle than the GateIn community project, we have our own maintenance branch where we forge bugfixes for our customers before contributing them back to the gatein trunk. For versions coming out of this eXo branch we will use -PLF qualifier.
FREE WHITE PAPER
Benefits of Open Source Software
for the Enterprise
for the Enterprise
The term open source refers to any solution that has its source code widely accessible to the public for modification and sharing.
Which version should you use?
At eXo, we don’t typically promote alpha releases outside of the company. They are technical milestones that are meaningful to our developers. For those eXo fans looking to satisfy their curiosity, we do make alpha releases available through our software factory.
With beta releases, we will sometimes promote them outside eXo — usually when innovative new features are introduced. Developers are encouraged to look at our betas and provide feedback. However, beta releases should never be put into production — they are unstable by nature and we cannot ensure they will not break your system. In addition, betas are not covered by our subscription support. Using a beta can be fine to build a demo, but not much more. We also recommend not starting a project on a beta version, with the expectation that eXo will release a GA by the time of your production target.
Use exclusively GAs and maintenance versions in production. Always upgrade to the latest maintenance version shortly after it is made available to you.
Finally, use CPs only if eXo advises it to you specifically. The CP versions are made on a case by case basis, generally if your production imperatives depend on it.
eXo Platform 6 Free Datasheet
Download the eXo Platform 6 Datasheet and
discover all the features and benefits
discover all the features and benefits
- Tags: eXo, Digital workplace, Tutorial
Julian dubois
Je suis expert solution chez eXo Platform.
Mon rôle est d’accompagner les clients dans le déploiement de leur projet de plateforme et l’accompagnement au changement lié à ce projet. J’ai piloté et administré une Digital Workplace pendant 3 ans avant de rejoindre eXo Platform.
Améliorer l’environnement et les conditions de travail m’a toujours passioné, je peux maintenant accompagner nos clients dans cette démarche.
Related posts
- All
- eXo
- Digital workplace
- Employee engagement
- Open source
- Future of work
- Internal communication
- Collaboration
- News
- intranet
- workplace
- Knowledge management
- Employee experience
- Employee productivity
- onboarding
- Employee recognition
- Change management
- Cartoon
- Digital transformation
- Infographic
- Remote work
- Industry trends
- Product News
- Thought leadership
- Tips & Tricks
- Tutorial
- Uncategorized
Laisser une réponse
( Votre adresse email ne sera pas publiée)
Connexion
0 Comments