[Releasing] HEADS-UP: Branching from 'dev' to '5.9' started

[Jason H]

> Sent: Tuesday, January 31, 2017 at 3:09 AM
> From: "Tuukka, Turunen" <tuukka.turunen at qt.io>

> > > The support contract is very good for bugs,  but for anything else,
> > > it's just throwing it over a wall and hoping a developer picks it up,
> > > leading me to be vocal on the mailing lists.
> > 
> > And that's ok. I appreciate hearing you, because I get to hear what's
> > important to you and to others. As I said, I'm not privy to the discussion
> > between you and your support contact. They can't release your name to me
> > either, so I don't know behind a report whether how many would want the
> > feature.
> > 
> 
> Both of the mentioned issues are known by support and in the priority queue. One of them is in progress and the other not yet. Being in the priority queue does not automatically mean the bug (or feature request) gets implemented immediately, but we do take into account factors such as how many licenses the customer has, how many other customers have reported it, what the regular bug priority is, can it be worked around or does it completely block the customer, how big an effort it is, etc. 
> 

Thanks for the insight. I completely acknowledge that my startup is a small fish in a big pond, and I have the utmost respect for the project, having it be my absolute favorite tech and using it professionally since 2004. The features I suggest, I mean _really_ suggest (I know I throw a lot of "what ifs" out there) and push for I make sure would benefit everyone. Generally these issues come from a lack of foresight about how the tech will be used in the wild, which is impossible to predict. Many times these can be a big fix, but on occasion they need an API change. Qt is a little more difficult in that it has a self-imposed binary compatibility requirement (which works to various degrees, but that's another discussion). The two API changes that I requested stem from a lack of API completeness. I figure API completeness would have it's own dimension in prioritization? 

The two issues (so you don't have to search):
The QML LocalStorage API used a private function for file path, so it could not share the location of its database (say for use with QSqlDatabase on the C++ side), without reverse engineering the local storage file naming function. (And there is no guarantee that Qt won't change it later). There is now a patch for that, but I don't know if I'll get pulled into 5.9... https://codereview.qt-project.org/#/c/181736/

The other one, the current Font comes from using QML Text Fit settings - there is no way to determine what it ended up using. This is important when a designer tells you that a fint should take up 10% of the height of the screen, and the rest of the text should be relative to that. At first glance you could impose the same height constraint, but then when you go multi-line it's just not possible. There is now code for this and it's in!! (thanks Eskil & co!)  https://codereview.qt-project.org/#/c/184005/