Vavr Support Roadmap
⭐️ Today, we released Vavr 0.10.0 ⭐️
Personally, 0.10.0 is a very important release to me, because it solves a gordic knot. There were new features pending for more than a year while I mixed in backward incompatible changes targeting 1.0. I solved that, 0.10.0 is fully backward compatible to 0.9.3.
🎉 Now I am able to completely focus on Vavr 1.0. Yay! 🎉
I will not give you a release date of 1.0. However, I already think about the support. From time to time there are questions on our issue tracker:
🤔 what's going to happen with VAVR 0.9.x branch, (...) given VAVR 1.0.x is not going to be backward compatible (...) does it mean that 0.9.x maintenance will finish?
Both, the 0.x line and the 1.x line will be maintained, currently without end of life dates. While 0.x will stay backward compatible, 1.x will be a complete rewrite of Vavr. I will keep as much of the existing structure and types, as possible. You will be familiar with 1.0 if you know 0.x. But 1.0 has to introduce backward incompatible changes in order to profit from our learned lessons.
🤔 Maybe a VAVR 1.0.x should be the name for the line of 0.9.x and VAVR 1.0.x should go to 2.0.X?
It is important to understand that we generally follow semantic versioning. We shift the major version when we introduce backward incompatible changes. However, in parallel we have certain release lines. While no one is able to guarantee eternal backward compatibility, it is important to us to ship drop-in replacements. A mandatory requirement is therefore to avoid backward incompatible changes.
It is a self-imposed goal not to make backward incompatible changes to a release line <major>.x.y. However, sometimes it is necessary to fix bugs like generic bounds that introduce source compatibility issues. Also, I do not plan to often introduce new major releases. It will take years to collect enough use-cases, requirements, lessons learned, etc in order to justify breaking changes.
Given that, it helps to keep the API surface area as small as possible. That's is my goal for Vavr 1.0.
Please note that I make use of deprecations in order to give you hints about API changes. A deprecation of a method does not necessarily mean that I plan to remove it. Removals can only appear in a major release. Please also note that removals do not necessarily require that there was a prior deprecation.
I hope this helps to understand
- how we are maintaining Vavr
- how we are dealing with API changes
- what our versioning scheme looks like
- how we plan to support Vavr for the next years
Have fun and stay pure!
- Daniel
