> On 10 Jul 2025, at 14:37, Marc Mutz via Development > <development@qt-project.org> wrote: > > Hi, > > I'm coming back to this thread, because this conclusion: > > > Confidential > On 18.03.24 16:28, Volker Hilsheimer wrote: > [...] >> >> to use those APIs you have to read the code. And >> then you’ll see that they are either undocumented, or documented as >> \internal. >> >> You can still use them, but you know that they might change. > [...] > > is being challenged for a recent change of mine that renamed > undocumented QArrayData::ref_ to m_ref¹. There's a growing pile of reviewers > that don't like the change, mainly because it breaks QtC (a fix is > available already², there's also a revert³ of the original change) > > ¹ https://codereview.qt-project.org/c/qt/qtbase/+/651494 > ² https://codereview.qt-project.org/c/qt-creator/qt-creator/+/660083 > ³ https://codereview.qt-project.org/c/qt/qtbase/+/660072 > > With the above rule, undocumented is equivalent to private. In particular, > you have to assume that undocumented API changes at any time. > > We now see how loud the outcry is when such changes, routinely done > every week, happen to hit one of our own tools with a vocal developer base.
The questions whether we allow certain changes, and whether we should make certain changes, are related but somewhat orthogonal. A drive-by change that renames a variable from “name I don’t like” to “name I like” seems arbitrary and unnecessary, especially in stable branches. I do question that (or if, why) such changes are “routinely done every week”. We do all have our own and different itches to scratch, but to me it seems to be a curious way to spend summer ;) > Do we still uphold the rule? I will bow to the decision, but either the > change is allowed alongside all others, or none are. It can't be that > we apply double standards. If the committer, and reviewer, and maintainer agree that the change is necessary and moves us forward (at the expense of some minor number of users experiencing discomfort), and accept the responsibility for dealing with potential fallout (i.e. spending time discussing with the Qt Creator team), then that’s their privilege. As the Qt Project, we should be clear that using publicly accessible, but undocumented API (which includes everything in QtPrivate and similar namespaces), is done at the user's risk, doesn’t come with any BiC/SiC guarantees, and might result in breakages at any version bump. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
