Back to blog
Our team aims to release often and provide more flexibility for our users and ReportPortal team itself in feature implementation and delivery. Our priority is always to deliver the product to our users as soon as we can (without sacrificing the product quality). That gives us an opportunity to collect users' feedback earlier and adjust our development strategy following your needs and market trends.
Based on the above, we decided to review our versioning models and release flow and move toward the new ones:
Semi annual product releases
Regular service release
The previous approach to versioning
Previously we used the approach to versions when the services were updated dependently. For example, if there were changes in the API service, Auth service and UI service that are not related to each other, we still made a release of these services trying to link them with a common version. Using this approach, we tried to understand in advance in which service and ReportPortal version the next changes will occur. We always synchronized all our components by the biggest change.
With this approach, we often had to reschedule some features release when they were almost ready, but suddenly we urgently needed to update some component. Synchronization of services was causing problems, was painful and hard for the development process.
So, we decided to change the approach to versions. Now we have replaced the Product release approach into separate Product release and Service release.
The main difference of a new approach
With the new approach, all our components (API Service, Auth Service, UI Service, Analyzer Service, Job Service) will have their own independent versions. We refused to synchronize versions. For example, if the API Service has major changes at the release time, and the UI Service and Analyzer Service have minor or patch changes, then their versions will be different. In addition, if there is no connection between their changes, we can release them separately upon readiness.
Product release
The Product release will contain a set of new features and a set of different ReportPortal services’ versions. At the very beginning of Product delivery planning, we don’t know what versions of the components will be included in the next release.
We use Calendar Versioning for Product releases. So, Product releases have the following pattern: yy.minor.micro(optional)-build, e.g., 2023.1 or 2023.2.5-768.
Service release
Now we can release services separately from a Product release. Each service is independent of other services and has individual release and versioning. One important thing is to provide backward compatibility.
We use Semantic versioning for Service release.
New approach to versions allows us to make fast implementation, testing, and delivery of new features to our users as well as collect and incorporate users feedback in our product. Besides functional changes this approach will allow us to release non-functional changes like security fixes in base image or dependencies more easily.