With OBS Studio 31 on the horizon, it’s a good time to reflect on how our release process works and how we’ve been handling versioning. Over the years, we've experienced a lot of growth, and it’s been a journey to find the right balance between new features, stability, and clarity in how we label our releases.
OBS has been around for over ten years now, and in that time, it has grown significantly in terms of functionality, code complexity, and community size. With this growth came challenges, both in development and organization. While it’s a great problem to have, figuring out how to manage these growing pains hasn’t always been easy.
One of the areas that needed attention was our release process and versioning methods. Up until recently, we lacked a clear, consistent approach to how we numbered our releases. But with version 30, we’ve started to follow proper Semantic Versioning (SemVer) a lot more strictly.
Semantic Versioning is a system for labeling software versions in a logical, consistent way. It communicates the significance of changes so users and developers know what to expect from an update.
MAJOR.MINOR.PATCH
Ex. 30.0.1
In the past, our versioning was a bit… loose. We didn’t have a strict structure or consistency in deciding when to release a new version or how to label it. Releases would come when we felt there were enough new features or fixes to warrant one, and we’d assign a version number based on how significant we thought the changes were.
Sometimes a MAJOR version would include breaking changes, and other times it was simply a feature-packed release we wanted to highlight. This inconsistency could be confusing, and moving forward, we’ve committed to using MAJOR version numbers strictly for updates that fundamentally change how you use OBS or affect developers by modifying the API or dependencies.
A great example of why this change was needed is OBS 28.0. That release included an update to the UI framework we use, which broke compatibility with several plugins. In hindsight, our inconsistent use of MAJOR version bumps muddied the significance of this update, causing frustration among both users and developers. By sticking more closely to Semantic Versioning, we hope to avoid these kinds of issues in the future.
Going forward, you can expect MINOR version bumps to be more common. We’re aiming to limit MAJOR breaking updates to about once a year, though that timeline could shift to be more or less depending on the needs of the project.
To be clear, this doesn’t mean the project is slowing down. In fact, it’s quite the opposite. With clearer planning and more predictable versioning, we’ll be able to manage releases more efficiently. In the past 10 years, we’ve reached version 30, but over the next decade, we may not even hit version 40, simply because MAJOR releases will be less frequent. This is just a visual change to how we label updates, not a reflection of the pace or size of our changes.
Alongside our commitment to more structured versioning, we’re also working toward a more predictable release schedule. While we’re not enforcing strict deadlines for features or updates yet, we’re aiming for new releases roughly every 4 months. This loose schedule gives contributors and users a better idea of when to expect new features and fixes, without sacrificing quality by rushing development.
As we move forward, we’re excited to bring more structure to the OBS Studio release process, giving you clearer communication on what’s coming and when. By adopting a more standardized approach to versioning and scheduling, we hope to make OBS even better for both everyday users and developers who rely on it. We’re thrilled about what’s coming in version 31 and beyond—stay tuned!
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。