eZ Systems: Release Cycles and Version Names Simplified
eZ Systems has a rich history of leadership in the CMS arena, stretching back over 15 years. The way that we solve problems, the way that we craft our solutions, and even the way that we think about content and development-everything we do has been subject to thoughtful, careful reinvention as we've grown.
We've embraced transparency, releasing our core product to the open source community under the GPL license.
We've embraced community, by joining the thriving Symfony community with Symfony2 Full Stack as our new engine.
Most of all, we've embraced our users, carefully maintaining backwards-compatibility and standing shoulder-to-shoulder with our customers, partners, and the community as we change and grow together.
We're not afraid to make tough decisions, bold changes, and humbly refine our process as we strive to provide the best possible Developer Experience (DX) in the market.
One of the growing pains we've experienced has been to clearly communicate a simple, consistent naming convention for new versions of our products. After all, we've just been through a major period of transition from our original product (eZ Publish) to a brand-new product (eZ Platform).
In that regard, over the past several months we had been communicating both version numbers and release codenames: the year and months of the different releases. It might have been a bit confusing for some. We acknowledge that we've not been totally consistent, nor good at explaining/defining the scheme. We hope from now to clarify and simplify this. Read below as we explain our new conventions here with a fresh, clear approach and a consistent path forward into the future.
eZ Platform X.Y.Z: A Semantic Version Approach
Everything we do is built on eZ Platform. It is a brand-new product, so we've started at version 1.0.0 to reflect this exciting reinvention of our foundation. We're using Semantic Versioning, which you can read about at http://semver.org/ . As an open source project the clean, simple, informative semantic version numbers are all a developer needs to instantly see and understand where the product is at in its growth.
Changes to the first digit indicate a breaking change to the API, and developers know that they may need to implement a re-write of their code to continue consuming the API moving forward. The middle digit represents new features and functionality. The final digit represents patches, bug fixes and other forms of "oops" and "aha!" These numbers make up the semantic version number, so you'll see a lowercase letter "v" to signify that. You may see file names such as ezplatform-v1.3.0.tar.gz and ezplatform-demo-v1.3.0.tar.gz available for download.
As a sneak-peek into our future: once installed, you'll also be able to see the version of the installation in the eZ Platform User Interface:
eZ Enterprise: Versioning, Release Cycle, and Release Naming Going Forward
When it comes to eZ Enterprise, we need more than just a version number. eZ Enterprise (which is made of eZ Platform, eZ Studio and a set of maintenance and support services) follows a specific release cycle that defines precisely what to expect in terms of support and maintenance.
Our enterprise customers count on us to provide world-class service, support, and maintenance. We support our eZ Enterprise Subscription product on a rock-solid, predictable calendar cycle so you'll always know what you've got, where we're at in the product's lifecycle, and what is coming next.
This product lifecycle is based on two kinds of Enterprise releases:
- An annual release with Long Term Support (LTS) for a minimum of 3 years
- A Fast Track (FT) release every other month to quickly bring our newest innovations to our users
For the LTS releases, we make them available right before the new year. Even though it's a couple weeks early, we name them against the year to come. For example, the LTS release that is coming in mid-December of 2016 will be called eZ Enterprise 2017.
In February of 2017, we'll do a Fast Track release, and again in April, June, August, and October of 2017. Because Fast Track releases are volatile (lifecycle of two months), we won't give them a specific name, despite the temptation to name them against the month and year. From now on only the semantic version will be used.
The version number of the eZ Enterprise download follows semantic versioning, just like everything else we do here at eZ Systems. Let's look at some examples. For a Long Term Support release, we'd name the file like this:
for a download that includes all the Composer packages for your convenience.
When you install and run eZ Enterprise, you'll be able to see all the information you need to know about the support cycle in the UI and on the Command Line, beginning in upcoming releases. Here's an example of what that might look like when it is ready:
The release notes will reference this semantic version number, and you'll have instructions in the README on how to view that version number; you'll always know what you've got and how to use it.
A couple of months after the Long Term Support release, the Fast Track release ships with a file name like this:
By looking at the file names, you can see that this version of eZ Enterprise has added features. This means machines (and gearheads alike) can track the incrementing values as eZ Enterprise continues to grow.
Remember the example filename we gave for a Long Term Support release, ezenterprise-v1.5.0.tar.gz? If you want to stay on that stable branch, you simply continue downloading patches such as ezenterprise-v1.5.1.tar.gz, ezenterprise-v1.5.2.tar.gz, ezenterprise-v1.5.3.tar.gz and so on. If you're feeling more adventurous, you can upgrade to the 1.6.x Fast Track to gain our latest innovations as well.
Once we reach the end of the year and have assembled the feature set we're ready to support for the long term, that becomes the next Long Term Support release for the following year. For example, perhaps it would be v1.12.0, or something similar. Remember, the middle digit gets a bump every time we add features, and then stays locked in for as long as we support that branch. For Fast Track innovations, that's only a couple of months (it really is a fast track!), but for Long Term Support you can count on maintenance for at least 3 years.
The Value of Semantic Versioning in Bundles and Dependencies
When you pop the hood on eZ Platform and eZ Enterprise, you'll see many components inside. Everything we do here is semantic. Each of the elements that we develop here at eZ Systems are assigned their own Semantic version number, just like the larger distributions that contain them.
You'll always be able to see what's included in a given version of eZ Platform, or in a given release of eZ Enterprise, but we won't muddy the waters by discussing these individually. Whether you're deciding how to version your own products or contributing a bundle to eZ Platform, we recommend that you join us in this standardized approach to naming all the things!
eZ Systems has two products:
- eZ Platform: Open Source CMS Product. Uses its own unique semantic version number: ezplatform-vX.Y.Z.tar.gz
- eZ Enterprise: Commercial Software Product. Based on eZ Platform with support and maintenance services, eZ Enterprise has its own unique semantic version number as well. To represent its unique contents, its version number is not tied to eZ Platform's version number and will grow at its own rate:ezenterprise-vX.Y.Z.tar.gz
These two products will increment their semantic version numbers independently from one another, following semver.org's conventions.
We hope this change helps to smooth things out moving forward. We believe this simplification of our version naming scheme will help us all to stay on the same page as we move forward, allowing us to focus on the thing that matters most: Content Management.
This simplification of our versioning and release naming will take some time to implement. If you would like to follow along, keep an eye on this epic in our Jira board:
We welcome your feedback!