TL;DR;
At Hoppscotch, we believe in providing our users with the best possible experience when it comes to API development. Our mission is to make API development simple, efficient, and user-friendly. With this goal in mind, we have decided to migrate from our current rolling releases to calendar version releases. This means that instead of constant, incremental updates, Hoppscotch will now be releasing one major update every quarter. Additionally, intermediate patch releases and hot fixes will be made available in between each major release.
One small step for Hoppscotch, one giant leap for our release numbering
Since our initial launch, Hoppscotch has used Semantic Versioning in our release cycle guidelines. Three years, three major releases, and n-patch fixes later, we're making the switch to Calendar Versioning. This means subscribers to our release notes will see quite the jump in today's version numbering, from the latest v3.0.1 to today's v2023.4.0.
Why the switch?
Rolling releases are a continuous stream of updates that are released as soon as they become available. This approach can be convenient for some users, as they always have access to the latest features and bug fixes. However, it can also lead to some challenges, such as stability issues and compatibility problems with other systems.
The reason for this change is to provide a more stable and predictable environment for Hoppscotch users. With constant updates, developers can find it difficult to keep up with the latest changes and ensure that their code remains compatible. By limiting the number of major updates and making the release schedule more predictable, developers can better plan and manage their development work.
To address these challenges and provide our users with a better experience, we have decided to move to calendar version releases. This approach involves releasing one major version every quarter, with intermediate patch releases and hot fixes in between. This will provide our users with a more stable and predictable release cycle, while still ensuring they have access to the latest features and bug fixes.
Notes on numbering
One of the key benefits of calendar version releases is that they allow us to focus on quality assurance and stability. We can spend more time testing our releases and fixing bugs, which will result in a more stable and reliable platform for our users. Additionally, calendar version releases allow us to plan for compatibility with other systems and ensure that our users can upgrade to the latest version with ease.
In addition, the calendar version model will make it easier for developers to stay up-to-date with the latest features and functionality. Instead of constantly having to make small updates, developers will only have to make major updates every quarter. This will save time and make the development process more efficient.
One of the biggest advantages of the calendar version release model is that it allows for better testing and quality assurance. With each major release, Hoppscotch will be able to perform more thorough testing and address any bugs or issues that are discovered. This will lead to a more stable and reliable platform, which will be a great benefit to both developers and end-users.
Key Takeaways:
- The change aims to improve app quality and stability.
- Major releases will be limited to one per quarter.
- The Hoppscotch team will have more time to test and refine each release.
- Users can expect a reliable and consistent experience.
- The app will perform smoothly and seamlessly on any device or platform.
Another benefit of calendar version releases is that they provide a clear roadmap for our users. With one major release per quarter, our users will know when to expect new features and enhancements, and can plan accordingly. This also makes it easier for our users to upgrade to the latest version, as they will have a clear understanding of what changes are coming and when they will be available.
The intermediate patch releases and hot fixes will also provide an important benefit. In between each major release, Hoppscotch will be able to address any critical bugs or issues that are discovered. This will ensure that users can continue to use the platform without interruption, while also providing the peace of mind that any important issues will be addressed in a timely manner.
In addition to improving quality, this change will also make it easier for the Hoppscotch team to address any bugs or issues that may arise. With fewer major releases, the team will be able to focus their resources on fixing any problems that are reported, ensuring that users are able to continue using the app without interruption. The intermediate patch releases and hot fixes in between the major releases will provide users with the necessary updates and improvements that they need to keep their projects running smoothly.
In conclusion, the migration to calendar version releases is an important step forward for Hoppscotch. By improving quality and stability, making it easier to address bugs and issues, and providing users with a clear timeline for new features and updates, with this change, Hoppscotch is positioning itself as a leader in the API development space, and is committed to delivering a high-quality and reliable platform to its users.
Whether you are an experienced developer or just starting out, Hoppscotch is the ideal platform for bringing your APIs to life and sharing them with the world. So why not give it a try today and see what you can create?
Top comments (1)
Hi Liyas,
reading your article, it seems to me that the goal actually was to switch from rolling releases, to scheduled realeases, is that right?
If so, then that does not affect the versioning scheme you are using.
It seems to me that hoppscotch should continue to use SemVer, as it expresses compatibility of the API with clients which want to use it.
I have released an article (1) suggesting what versioning scheme to use for what kind of software product→ ( it is in german, but an online translator might help ).
It is inspired by this article.
Leave me your thoughts about whether or not you think SemVer should be the choice after reading the article.
Looking Foward to hear from you,
Mustafa
(1) the article on when to use SemVer, CalVer and NameVer→