On Fri, 24 Apr 2020 at 13:38, Edward Welbourne <edward.welbou...@qt.io> wrote: > > On 4/23/20 11:10 PM, Vitaly Fanaskov wrote: > >> Moving to one year release approach doesn't equal to make Qt less stable. > > Ville: > > Of course it does, if we now allow API breaks every year. > > Not necessarily: if we *allow* API breaks every year *but* are > restrained in our use of them - so that, in fact, over a given ten year > period, we only make as many API breaks; we just spread them out over > time more evenly - then we'd be no less stable; and it'd be easier for > client code maintainers to keep up with our major version updates, > because they'd be smaller.
That is still less stable. The more frequent the API breaks are, the less stable the API is. The size of the API break matters as well, but that's easier to control; I make the decision whether to jump now or later, and the size of the break to a large extent affects what the schedule of the jump is, not that much whether to take a jump (unless it's so large as to be over the breaking point, of course). If I'd need to consider such a jump every year, I'd switch to something else, including changing the programming language if need be. Annual API breaks are untenable for any product that has a limited budget. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
