That would be great, thank you!
Thanks *Ovilia* On Wed, Oct 9, 2024 at 12:08 AM Ville Brofeldt <ville.v.brofe...@gmail.com> wrote: > Hi Ovilia, > > Not a problem at all! Ok, this is good to know. If you're open to adding a > note about the versioning scheme, I'd be happy to draft a PR to make the > policy more explicit. > > Kind regards, > > Ville > > On Oct 7, 2024, at 8:38 PM, Ovilia <oviliazh...@gmail.com> wrote: > > Hi Ville, > > Sorry for the late reply because we are on vacation lately. > > I appreciate your email and understand your concern about users > potentially encountering unexpected breaking changes in a minor release. > However, given that major releases occur over several years, it’s not > always feasible to strictly adhere to semantic versioning and delay > breaking changes until a major release. Therefore, our approach is to avoid > introducing breaking changes in patch releases and to clearly document any > breaking changes in the changelog when they do occur. > > Thanks > > *Ovilia* > > > On Thu, Sep 26, 2024 at 6:57 AM Ville Brofeldt <ville.v.brofe...@gmail.com> > wrote: > >> Hello all, >> >> On Apache Superset, we recently encountered an issue when upgrading >> ECharts from 5.4.1 to 5.5.1. A breaking change introduced in #19513 < >> https://github.com/apache/echarts/pull/19513> caused a regression, which >> we identified after reviewing the changelog. While this wasn’t a major >> issue to resolve, we were under the impression that ECharts followed >> semantic versioning, where breaking changes would have resulted in a major >> version bump (in this case 6.0.0). >> >> I understand that it might be preferable to base major releases on the >> introduction of significant new features, but it seems that many users or >> organizations could encounter unexpected issues during upgrades, as they >> may assume a minor version bump won’t introduce breaking changes. >> >> To help clarify expectations, a few potential alternatives come to mind: >> >> Keep the current versioning scheme, but add documentation to clarify how >> major, minor, and patch releases are structured. >> Adopt Semantic Versioning, and always bump the major version when a >> breaking change is introduced. >> Adopt Semantic Versioning, but defer the introduction of breaking changes >> to major releases. >> Please note, this isn't a complaint, but rather a suggestion to make the >> versioning logic clearer so that the community can better understand what >> to expect during updates. I’d love to hear what others think about this. >> >> Best regards, >> Ville > > >
