Over the past few years, TeamCity has been using the YYYY.R versioning scheme, where YYYY represented the year and R represented the release within that year. When looking at the version number 2021.2.1, for example, you could easily understand its meaning:
Similarly, the name of version 2022.1 EAP made it clear that this was an early preview of the first release for 2022.
Why do we need a new versioning scheme?
While this versioning scheme worked great for many years, the release of TeamCity Cloud has brought about a paradigm shift:
Instead of releasing new features only twice a year, we can now deliver them to you as soon as they are ready – in the cloud.
Moving to a new development cycle means we need to rethink our versioning scheme, not only so we can ship new features faster and be more flexible with releases, but also so we can maintain a transparent workflow in our issue tracker.
The new scheme
After exploring different options, we’ve decided that a calendar versioning scheme with the YYYY.MM.MINOR structure will provide the best possible clarity for our users. This versioning scheme is used by many other popular products (for example, Ubuntu), and we believe that most of our users will be able to understand it easily.
According to this new system, the next major releases of TeamCity On-Premises will be named as follows:
- 2022.04 instead of 2022.1
- 2022.10 instead of 2022.2
- 2023.04 instead of 2023.1
- 2023.10 instead of 2023.2
We are planning to release new major versions of TeamCity On-Premises every April and October, which correspond to the 04 and 10 in the version numbers. Bug-fix releases will increment the third number in the version independently of the month when they are released: e.g. 2022.04.1, 2022.04.2, 2022.04.3, etc.
TeamCity Cloud vs. EAP releases
After the release of TeamCity Cloud several months ago, it quickly became obvious to us that there’s no longer any real advantage in releasing EAP versions. Because of this, we’ve decided to discontinue the TeamCity EAP and focus on more stable releases of TeamCity Cloud instead:
Unlike in the early access builds that we previously published before releasing the major versions, all features in the TeamCity Cloud releases will be polished and ready to be used in production.
For obvious reasons, new features that are specific to TeamCity On-Premises (such as administration or multiserver setup) will not appear in the TeamCity Cloud releases.
There is one exceptional scenario in which it will still be possible to download early access builds of TeamCity On-Premises – more on this below.
What you will see
As a user of TeamCity On-Premises (Professional, Enterprise)
- You will still get new major versions of TeamCity twice a year, as the release cycle will remain the same for the On-Premises version. The April and October releases will be named 2022.04 and 2022.10, respectively.
- Minor (bug-fix) updates will be delivered as usual, approximately once per month.
- For new customers of TeamCity Enterprise, understanding which versions can be used with their subscriptions will be easier than ever. Let’s say you purchased a license in December 2021, and you want to understand whether it will be valid for version 2022.10. All you need to do is add one year to 2021.12, and then compare the two numbers. 2021.12 is higher than 2021.10 – so the answer is yes, you can upgrade for free.
As a user of TeamCity Cloud
- You will receive all the latest features as soon as they are ready. 🚀🚀🚀
- You will no longer see the product version inside the TeamCity Cloud user interface.
- New TeamCity Cloud versions will be arriving approximately every two months, and we will automatically roll out these updates according to our Cloud maintenance guidelines.
As a plugin developer
- You will no longer be able to test your plugins on EAP builds.
- We will provide a way to download a distribution corresponding to the latest version of TeamCity Cloud, which you will be able to use to test your plugins (this is the exceptional scenario mentioned earlier). These distributions will follow the YYYY.MM versioning scheme described above, e.g. 2021.12, 2022.02, etc.
Share your thoughts
This new pipeline aims to make our releases more flexible and their features more stable. If you have any questions regarding these changes, feel free to leave a comment on this post and we will try to answer you.