Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
Great! Hopefully the remaining steps towards alpha go nicely. There are quite a few items not yet listed at: https://wiki.qt.io/New_Features_in_Qt_5.15 The new feature highlight is valuable for users, so please lift a few of the key items for each module into the list. Think what are the most important items to tell our users. We should have more content in place before the alpha, and finalize this before the first beta release. Yours, Tuukka On 11.2.2020, 11.12, "Development on behalf of Volker Hilsheimer" wrote: > On 10 Feb 2020, at 13:44, Jani Heikkinen wrote: > > Hi all, > > It seems that there is still some work needed to finalize deprecations and replacement for Qt 5.15 > > We had some discussion here in Qt Company and based on that I propose: > > - Let's put Alpha out after this header view feature is in. HeaderView change merged this morning: https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/270170 so we should be good to go with the Alpha. Cheers, Volker > - Let's agree these deprecations can be done still even the FF is in effect. But let's try to finalize deprecations and replacements as soon as possible. Blocking Alpha until all these are in doesn't make sense at this point anymore. > - Before Beta1 these deprecations needs approval of module maintainer > - And after Beta1 adding new deprecations needs Lars's approval > > That should bring us enough flexibility in this special situation without compromising or risking the Qt 5.15 release schedule too much. > > br, > jani > > > > >> -Original Message- >> From: Development On Behalf Of >> Jani Heikkinen >> Sent: torstai 6. helmikuuta 2020 10.03 >> To: Mitch Curtis ; Lars Knoll ; Yulong >> Bai >> Cc: Qt development mailing list ; >> releas...@qt-project.org >> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is >> in effect now >> >>> -Original Message- >>> From: Mitch Curtis >>> Sent: keskiviikko 5. helmikuuta 2020 15.40 >>> To: Jani Heikkinen ; Lars Knoll >>> ; Yulong Bai >>> Cc: Volker Hilsheimer ; Qt development >>> mailing list ; releas...@qt-project.org >>> Subject: RE: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature >>> Freeze is in effect now >>> >>> >>> Hi Jani. >>> >>> - It's a vital part of creating a table in Qt Quick, and something >>> that is non- trivial for a good chunk of users to implement themselves. >>> - I think you and Lars have already said it's low risk, which is true. >>> - I don't think this counts as justification, but.. it's been in the >>> works for a while, and we really shouldn't delay it any longer. >>> - I'm also confident we will be ready to merge it today. >> >> Hi, >> >> Ok, nice to hear it won't take that long to get this in. And based on all >> discussion related to this & qt5.15 overall let's take this in Qt 5.15. >> >> We have other issues delaying alpha packages as well so this won't be only >> thing delaying it Let's try to finalize alpha content during this week & get >> Alpha out during next one >> >> Br, >> Jani >> >> >> ___ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
> On 10 Feb 2020, at 13:44, Jani Heikkinen wrote: > > Hi all, > > It seems that there is still some work needed to finalize deprecations and > replacement for Qt 5.15 > > We had some discussion here in Qt Company and based on that I propose: > > - Let's put Alpha out after this header view feature is in. HeaderView change merged this morning: https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/270170 so we should be good to go with the Alpha. Cheers, Volker > - Let's agree these deprecations can be done still even the FF is in effect. > But let's try to finalize deprecations and replacements as soon as possible. > Blocking Alpha until all these are in doesn't make sense at this point > anymore. > - Before Beta1 these deprecations needs approval of module maintainer > - And after Beta1 adding new deprecations needs Lars's approval > > That should bring us enough flexibility in this special situation without > compromising or risking the Qt 5.15 release schedule too much. > > br, > jani > > > > >> -Original Message- >> From: Development On Behalf Of >> Jani Heikkinen >> Sent: torstai 6. helmikuuta 2020 10.03 >> To: Mitch Curtis ; Lars Knoll ; Yulong >> Bai >> Cc: Qt development mailing list ; >> releas...@qt-project.org >> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is >> in effect now >> >>> -Original Message- >>> From: Mitch Curtis >>> Sent: keskiviikko 5. helmikuuta 2020 15.40 >>> To: Jani Heikkinen ; Lars Knoll >>> ; Yulong Bai >>> Cc: Volker Hilsheimer ; Qt development >>> mailing list ; releas...@qt-project.org >>> Subject: RE: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature >>> Freeze is in effect now >>> >>> >>> Hi Jani. >>> >>> - It's a vital part of creating a table in Qt Quick, and something >>> that is non- trivial for a good chunk of users to implement themselves. >>> - I think you and Lars have already said it's low risk, which is true. >>> - I don't think this counts as justification, but.. it's been in the >>> works for a while, and we really shouldn't delay it any longer. >>> - I'm also confident we will be ready to merge it today. >> >> Hi, >> >> Ok, nice to hear it won't take that long to get this in. And based on all >> discussion related to this & qt5.15 overall let's take this in Qt 5.15. >> >> We have other issues delaying alpha packages as well so this won't be only >> thing delaying it Let's try to finalize alpha content during this week & >> get >> Alpha out during next one >> >> Br, >> Jani >> >> >> ___ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
Hi all, It seems that there is still some work needed to finalize deprecations and replacement for Qt 5.15 We had some discussion here in Qt Company and based on that I propose: - Let's put Alpha out after this header view feature is in. - Let's agree these deprecations can be done still even the FF is in effect. But let's try to finalize deprecations and replacements as soon as possible. Blocking Alpha until all these are in doesn't make sense at this point anymore. - Before Beta1 these deprecations needs approval of module maintainer - And after Beta1 adding new deprecations needs Lars's approval That should bring us enough flexibility in this special situation without compromising or risking the Qt 5.15 release schedule too much. br, jani > -Original Message- > From: Development On Behalf Of > Jani Heikkinen > Sent: torstai 6. helmikuuta 2020 10.03 > To: Mitch Curtis ; Lars Knoll ; Yulong > Bai > Cc: Qt development mailing list ; > releas...@qt-project.org > Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is > in effect now > > > -Original Message- > > From: Mitch Curtis > > Sent: keskiviikko 5. helmikuuta 2020 15.40 > > To: Jani Heikkinen ; Lars Knoll > > ; Yulong Bai > > Cc: Volker Hilsheimer ; Qt development > > mailing list ; releas...@qt-project.org > > Subject: RE: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature > > Freeze is in effect now > > > > > > Hi Jani. > > > > - It's a vital part of creating a table in Qt Quick, and something > > that is non- trivial for a good chunk of users to implement themselves. > > - I think you and Lars have already said it's low risk, which is true. > > - I don't think this counts as justification, but.. it's been in the > > works for a while, and we really shouldn't delay it any longer. > > - I'm also confident we will be ready to merge it today. > > Hi, > > Ok, nice to hear it won't take that long to get this in. And based on all > discussion related to this & qt5.15 overall let's take this in Qt 5.15. > > We have other issues delaying alpha packages as well so this won't be only > thing delaying it Let's try to finalize alpha content during this week & get > Alpha out during next one > > Br, > Jani > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On Thursday, 6 February 2020 05:51:17 PST Alex Blasche wrote: > Either option solves the ambiguity. What's more important to our users - a > consistent naming convention or an early warning/compile error when > adopting Qt 6? False dichotomy. Both are important and both are achievable. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On Wednesday, 5 February 2020 15:34:27 PST Alexander Akulich wrote: > Do we want to sort out all overloads of error() signal/getter in all > (essential?) modules for Qt 6? > > For example, Qt Multimedia still has more than a dozen public classes > with such overloads (of a signal and a getter) in 5.15 and dev. We wanted to do it for 5.6, so 6.0 seems like early enough, yes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
I started to work on the error() signal renaming here: https://codereview.qt-project.org/q/topic:%22error-occured%22 On Wed, Feb 5, 2020 at 10:12 PM Thiago Macieira wrote: > > On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote: > > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira > > > > wrote: > > > The correct signal for an error situation is errorOccurred, like in > > > QLocalSocket and QProcess. > > > > Actually both QLocalSocket and QAbstractSocket renamed the "error()" > > getter to keep using "error()" signal as opposed to many other Qt > > modules "errorOccurred()" signals. > > Which is the opposite of QProcess and violates the naming convention. Signals > are named after verbs in the past tense and properties & property getters are > simple nouns. So "error" is the getter, "errorOccurred" is the signal. > > qprocess.h: > > #if QT_DEPRECATED_SINCE(5, 6) > QT_DEPRECATED_X("Use QProcess::errorOccurred(QProcess::ProcessError) > instead") > void error(QProcess::ProcessError error); > #endif > void errorOccurred(QProcess::ProcessError error); > > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
Hi, In practice we also do have some slack in the schedule exactly to allow sorting everything out. Unfortunately it is often not long enough, but we have delay in getting the alpha out. I do agree that we should include the features that are ready in time - and I do not think there are many who would disagree. One thing that tends to happen is the last minute pile up of commits at or near the FF time. While understandable, the more we can do to avoid this the more likely it is to have successful integrations. Especially with Qt 6 we need to make sure as many items as possible are not piling up just at the FF date. Maybe we should set a bit earlier FF date for the modules most others depend upon? Or other similar phasing instead of a day when everything needs to be in. Yours, Tuukka On 7.2.2020, 9.59, "Releasing on behalf of Eskil Abrahamsen Blomfeldt" wrote: On 05.02.2020 13:04, Jani Heikkinen wrote: > >> -Original Message- >> From: Eskil Abrahamsen Blomfeldt >> Sent: keskiviikko 5. helmikuuta 2020 13.06 >> To: Edward Welbourne ; Jani Heikkinen >> ; Lars Knoll ; Volker Hilsheimer >> >> Cc: Qt development mailing list ; >> releas...@qt-project.org >> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is >> in effect now >> >> >> On 05.02.2020 11:50, Edward Welbourne wrote: >>> Jani Heikkinen (5 February 2020 06:42) >>>> Why this is so important that we should get the exception & go in after >> FF? >>> Do we allow changes approved before feature freeze to get past the >>> Coin hurdle, even if that happens after FF ? How much fixing of the >>> change (if it turns out to have problems integrating) is acceptable, >>> before we declare that it's no longer the change that was approved in time >> ? >> >> >> If the change is ready and approved by the time of feature freeze and only >> delayed by CI problems, failures from other changes in a batch, or the >> awkwardness of our dependency structure, I think it has to be acceptable to >> merge after the freeze. Otherwise feature freeze becomes a lottery where >> the features in a given release is based mostly on chance. > By default we shouldn't put any new features in after FF, not even those which were approved early enough. Not respecting the freeze date was one of biggest reasons why we failed to keep the release schedule with earlier releases. And after we started to be much tighter with the freeze we have been much better to keep the schedules as well... Hi, You are looking at this from a very different perspective than me, which is totally understandable. As a developer of the product, I want a deadline for when I should have my feature finished. If the deadline is "maybe one month before the feature freeze, maybe one week, who knows it kind of depends on whether the CI system is acting up and what other changes your fix happens to be bundled with", then that makes it impossible to plan anything. If we estimate, based on statistics, that it will take one month to get features in, then we should set the feature freeze one month earlier. If we think it will take one week, then we should set it one week earlier. At least we should give people a specific date and guarantee that if they make it in time for this, their change will be in the next release. If this is one month before the actual feature freeze, then so be it. If it takes that long to get a change in, then definitely should be very visible to everyone, including the stake-holders who depend on features being released when we say. If it turns out that we miscalculated the estimate, then this should just cause a delay to the release. It shouldn't cause us to make a release containing a random set of features based on whoever won the lottery this time. I understand that your responsibility is making the release on time, and late submissions make this difficult, but the way to solve this is to add the extra slack between the feature freeze and the point where we can start stabilizing to the release schedule. If we see that changes that are staged at the freeze date consistently take between 1 day and 1 week to merge because we have broken systems or because so many people stage their changes at the same time, then that means we have to extend the period between freeze and release by one week. > We are doing time based releases so if new feature misses the deadline > there will be next one coming after f
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On 05.02.2020 11:50, Edward Welbourne asked: Do we allow changes approved before feature freeze to get past the Coin hurdle, even if that happens after FF ? How much fixing of the change (if it turns out to have problems integrating) is acceptable, before we declare that it's no longer the change that was approved in time ? Eskil Abrahamsen Blomfeldt (keskiviikko 5. helmikuuta 2020 13.06) replied: >>> If the change is ready and approved by the time of feature freeze >>> and only delayed by CI problems, failures from other changes in a >>> batch, or the awkwardness of our dependency structure, I think it >>> has to be acceptable to merge after the freeze. Otherwise feature >>> freeze becomes a lottery where the features in a given release is >>> based mostly on chance. Makes sense. See below. On 05.02.2020 13:04, Jani Heikkinen wrote: >> By default we shouldn't put any new features in after FF, not even >> those which were approved early enough. Not respecting the freeze >> date was one of biggest reasons why we failed to keep the release >> schedule with earlier releases. And after we started to be much >> tighter with the freeze we have been much better to keep the >> schedules as well... Eskil Abrahamsen Blomfeldt (7 February 2020 08:58) > You are looking at this from a very different perspective than me, > which is totally understandable. Indeed - still, let us all try to see this from each others' perspectives. That gives a better chance of finding a resolution we can all be happy with. > As a developer of the product, I want a deadline for when I should > have my feature finished. If the deadline is "maybe one month before > the feature freeze, maybe one week, who knows it kind of depends on > whether the CI system is acting up and what other changes your fix > happens to be bundled with", then that makes it impossible to plan > anything. On the other hand, if a change that should be subject to FF turns out to have problems that mean it wasn't actually ready in time, how severe can those problems be and *not* imply that we should keep that feature out ? This week, we've given special dispensation for things that were delayed due to minor problems that were known at the time of FF. That seems a reasonable level of flexibility in an otherwise hard FF. If a change that seemed ready for merge last Friday turns out to cause problems that weren't anticipated then, unless they are promptly resolved and low-risk (given the previously accepted change), it makes sense to block that change until the next release - otherwise, the release process becomes chaos, as it voids FF's rule about what's in and what's out. [snip] > The next one will be coming after six months in most cases (Qt 5.15 is > special of course). This is a pretty long time. But more importantly, > expecting every single developer in the Qt community to internalize > the flakiness of the CI system or the risk that your change may be > rejected because it happened to be bundled with a broken change is the > wrong angle in my opinion. I don't think anyone is currently standing for that position: if the only thing that's kept a change out is CI failure, or being staged alongside someone else's broken change [0] on the day of FF, then I think we're all in agreement that the change "made it in time". On the other hand, the broken change whose premature staging blocked others' changes from getting integrated *should* be subject to scrutiny - if it can be fixed safely, satisfactorily and promptly then fine, but if it's going to delay other changes with further integration failures then we should be ready to Just Say No to it after the FF deadline passes. [0] and you know which change I'm thinking of, Eskil. I'm happy to see it got fixed up quickly ;^> We presently have (only semi-formally) a process that requires API changes to be in by the FF deadline but provides for community (i.e. this list) approval of stragglers, when we are confident they are unlikely to harm stability or schedule. That seems workable. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
> Edward Welbourne > > Alexander Akulich (6 February 2020 16:33) asked: > > Are we going to provide some Qt5 → Qt6 migration tool? > > https://codereview.qt-project.org/c/qt/qtrepotools/+/289121 > > > It is trivial to grep the sources for > > "SIGNAL(error(QAbstractSocket::SocketError))" and print a warning > > about the dangerous Qt4-style connection. > > Check with Friedemann on the review, but I suspect he'd welcome a patch that > adds that to the tool. I think clazy has a check for this already? https://github.com/KDE/clazy/blob/master/docs/checks/README-old-style-connect.md Mark ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On 05.02.2020 13:04, Jani Heikkinen wrote: > >> -Original Message- >> From: Eskil Abrahamsen Blomfeldt >> Sent: keskiviikko 5. helmikuuta 2020 13.06 >> To: Edward Welbourne ; Jani Heikkinen >> ; Lars Knoll ; Volker Hilsheimer >> >> Cc: Qt development mailing list ; >> releas...@qt-project.org >> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is >> in effect now >> >> >> On 05.02.2020 11:50, Edward Welbourne wrote: >>> Jani Heikkinen (5 February 2020 06:42) >>>> Why this is so important that we should get the exception & go in after >> FF? >>> Do we allow changes approved before feature freeze to get past the >>> Coin hurdle, even if that happens after FF ? How much fixing of the >>> change (if it turns out to have problems integrating) is acceptable, >>> before we declare that it's no longer the change that was approved in time >> ? >> >> >> If the change is ready and approved by the time of feature freeze and only >> delayed by CI problems, failures from other changes in a batch, or the >> awkwardness of our dependency structure, I think it has to be acceptable to >> merge after the freeze. Otherwise feature freeze becomes a lottery where >> the features in a given release is based mostly on chance. > By default we shouldn't put any new features in after FF, not even those > which were approved early enough. Not respecting the freeze date was one of > biggest reasons why we failed to keep the release schedule with earlier > releases. And after we started to be much tighter with the freeze we have > been much better to keep the schedules as well... Hi, You are looking at this from a very different perspective than me, which is totally understandable. As a developer of the product, I want a deadline for when I should have my feature finished. If the deadline is "maybe one month before the feature freeze, maybe one week, who knows it kind of depends on whether the CI system is acting up and what other changes your fix happens to be bundled with", then that makes it impossible to plan anything. If we estimate, based on statistics, that it will take one month to get features in, then we should set the feature freeze one month earlier. If we think it will take one week, then we should set it one week earlier. At least we should give people a specific date and guarantee that if they make it in time for this, their change will be in the next release. If this is one month before the actual feature freeze, then so be it. If it takes that long to get a change in, then definitely should be very visible to everyone, including the stake-holders who depend on features being released when we say. If it turns out that we miscalculated the estimate, then this should just cause a delay to the release. It shouldn't cause us to make a release containing a random set of features based on whoever won the lottery this time. I understand that your responsibility is making the release on time, and late submissions make this difficult, but the way to solve this is to add the extra slack between the feature freeze and the point where we can start stabilizing to the release schedule. If we see that changes that are staged at the freeze date consistently take between 1 day and 1 week to merge because we have broken systems or because so many people stage their changes at the same time, then that means we have to extend the period between freeze and release by one week. > We are doing time based releases so if new feature misses the deadline > there will be next one coming after few months. It might be quite long > time for unique feature but on the other hand it isn't really that > long... Our goal is to cut the schedule between FF and final release, > not reserving more time there. Ok, currently there is of course some > buffer in; Release plans are based on previous releases and realized > schedules there. But we should be able to develop our ways of working > & our release systems so that we can make that time much shorter. That > way we could get more time to develop new features. The next one will be coming after six months in most cases (Qt 5.15 is special of course). This is a pretty long time. But more importantly, expecting every single developer in the Qt community to internalize the flakiness of the CI system or the risk that your change may be rejected because it happened to be bundled with a broken change is the wrong angle in my opinion. We would just be distributing the responsibility of analyzing our release systems to hundreds of people instead of doing it once, as part of the release planning. So if you know how long it will typically take for a change to get in, then why
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
Den tors 6 feb. 2020 kl 20:36 skrev André Pönitz : > > On Thu, Feb 06, 2020 at 01:51:17PM +, Alex Blasche wrote: > > > > > -Original Message- From: Development > > > On Behalf Of Thiago Macieira > > > > > > On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote: > > > > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira > > > > > > > > wrote: > > > > > The correct signal for an error situation is errorOccurred, like in > > > > > QLocalSocket and QProcess. > > > > > > > > Actually both QLocalSocket and QAbstractSocket renamed the "error()" > > > > getter > > > > to keep using "error()" signal as opposed to many other Qt modules > > > > "errorOccurred()" signals. > > > > > > Which is the opposite of QProcess and violates the naming convention. > > > Signals > > > are named after verbs in the past tense and properties & property getters > > > are > > > simple nouns. So "error" is the getter, "errorOccurred" is the signal. > > > > Either option solves the ambiguity. What's more important to our users - a > > consistent naming convention > > or an early warning/compile error when adopting Qt 6? > > Consistent naming will be beneficial for a much longer time than any > short term incentive to adopt Qt 6. I'm with André, please focus on getting it consistent. It's one of the things I think many love about Q - they can guess what name a function will have (even without auto-complete). If this is not done for Qt 6 (a major) release, then what should it be done? (Never?). The gotcha introduced can be advertised in the release announcement, I think that's enough. My 2 cents. Elvis > > Andre' > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On Thu, Feb 06, 2020 at 01:51:17PM +, Alex Blasche wrote: > > > -Original Message- From: Development > > On Behalf Of Thiago Macieira > > > > On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote: > > > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira > > > > > > wrote: > > > > The correct signal for an error situation is errorOccurred, like in > > > > QLocalSocket and QProcess. > > > > > > Actually both QLocalSocket and QAbstractSocket renamed the "error()" > > > getter > > > to keep using "error()" signal as opposed to many other Qt modules > > > "errorOccurred()" signals. > > > > Which is the opposite of QProcess and violates the naming convention. > > Signals > > are named after verbs in the past tense and properties & property getters > > are > > simple nouns. So "error" is the getter, "errorOccurred" is the signal. > > Either option solves the ambiguity. What's more important to our users - a > consistent naming convention > or an early warning/compile error when adopting Qt 6? Consistent naming will be beneficial for a much longer time than any short term incentive to adopt Qt 6. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
Alexander Akulich (6 February 2020 16:33) asked: > Are we going to provide some Qt5 → Qt6 migration tool? https://codereview.qt-project.org/c/qt/qtrepotools/+/289121 > It is trivial to grep the sources for > "SIGNAL(error(QAbstractSocket::SocketError))" and print a warning > about the dangerous Qt4-style connection. Check with Friedemann on the review, but I suspect he'd welcome a patch that adds that to the tool. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
Are we going to provide some Qt5 → Qt6 migration tool? It is trivial to grep the sources for "SIGNAL(error(QAbstractSocket::SocketError))" and print a warning about the dangerous Qt4-style connection. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
> -Original Message- > From: Alexander Akulich > On Thu, Feb 6, 2020 at 4:52 PM Alex Blasche wrote: > > > > Considering that our naming convention for error() signals is inconsistent > anyway, I favour an approach that highlights API changes early. > > The convention can not be inconsistent. It can either do not exist ("we have > no > convention, so we're agreed to do whatever we want and have inconsistency in > the API") or it can exist, so we want to follow it by definition. Sorry, I should clarify. The current application of the convention is very inconsistent across the Qt modules already. I do not advocate to drop the convention especially when considering new API's. However sometimes there are extenuating circumstances which may provide reasons to not follow them. Under my proposal this would be such a case when weighing the two arguments. -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On Thu, Feb 6, 2020 at 4:52 PM Alex Blasche wrote: > > Considering that our naming convention for error() signals is inconsistent > anyway, I favour an approach that highlights API changes early. The convention can not be inconsistent. It can either do not exist ("we have no convention, so we're agreed to do whatever we want and have inconsistency in the API") or it can exist, so we want to follow it by definition. If we have the convention that goes against the API then it would make sense to either adjust/withdraw the convention or apply it at the right time for the latest minor Qt 5 release. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
> -Original Message- > From: Development On Behalf Of > Thiago Macieira > > On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote: > > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira > > > > wrote: > > > The correct signal for an error situation is errorOccurred, like in > > > QLocalSocket and QProcess. > > > > Actually both QLocalSocket and QAbstractSocket renamed the "error()" > > getter to keep using "error()" signal as opposed to many other Qt > > modules "errorOccurred()" signals. > > Which is the opposite of QProcess and violates the naming convention. Signals > are named after verbs in the past tense and properties & property getters are > simple nouns. So "error" is the getter, "errorOccurred" is the signal. Either option solves the ambiguity. What's more important to our users - a consistent naming convention or an early warning/compile error when adopting Qt 6? Considering that our naming convention for error() signals is inconsistent anyway, I favour an approach that highlights API changes early. From an API user's perspective, the errorOccurred() signal changes little of the existing inconsistency (code completion solves most of this problem too) but sets my up for an ugly runtime error. A renamed getter solves my ambiguity issues and the compiler tells me straight away that there is a change. Therefore I'd vote to keep it as is (after Timur's recent change) -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
> -Original Message- > From: Mitch Curtis > Sent: keskiviikko 5. helmikuuta 2020 15.40 > To: Jani Heikkinen ; Lars Knoll ; > Yulong Bai > Cc: Volker Hilsheimer ; Qt development mailing list > ; releas...@qt-project.org > Subject: RE: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is > in effect now > > > Hi Jani. > > - It's a vital part of creating a table in Qt Quick, and something that is > non- > trivial for a good chunk of users to implement themselves. > - I think you and Lars have already said it's low risk, which is true. > - I don't think this counts as justification, but.. it's been in the works > for a > while, and we really shouldn't delay it any longer. > - I'm also confident we will be ready to merge it today. Hi, Ok, nice to hear it won't take that long to get this in. And based on all discussion related to this & qt5.15 overall let's take this in Qt 5.15. We have other issues delaying alpha packages as well so this won't be only thing delaying it Let's try to finalize alpha content during this week & get Alpha out during next one Br, Jani ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
Do we want to sort out all overloads of error() signal/getter in all (essential?) modules for Qt 6? For example, Qt Multimedia still has more than a dozen public classes with such overloads (of a signal and a getter) in 5.15 and dev. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
This merged just now 邏 Will update wiki tomorrow. Apologies for not getting this finished earlier, and thanks for the flexibility Cheers, Volker From: Jani Heikkinen Sent: Wednesday, February 5, 2020 12:29:27 PM To: Volker Hilsheimer ; Edward Welbourne Cc: Lars Knoll ; development@qt-project.org ; releas...@qt-project.org Subject: RE: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now > -Original Message- > From: Volker Hilsheimer > Sent: keskiviikko 5. helmikuuta 2020 13.10 > To: Edward Welbourne > Cc: Jani Heikkinen ; Lars Knoll ; > development@qt-project.org; releas...@qt-project.org > Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is > in effect now > > > On 5 Feb 2020, at 11:50, Edward Welbourne > wrote: > > > > On 4 Feb 2020, at 16:56, Volker Hilsheimer > wrote: > >>>> I’ve been struggling a bit more than expected with getting the > >>>> implementation of "move a file or directory to the trash" pass CI. > >>>> It’s a popular feature request: > >>>> > >>>> https://bugreports.qt.io/browse/QTBUG-47703 > >>>> > >>>> The basic implementation and private APIs have been in for a bit, > >>>> but required a bit of follow-up, which delayed the merging of the > >>>> commit that adds the public API in: > >>>> > >>>> https://codereview.qt-project.org/c/qt/qtbase/+/287373 > > > > Lars Knoll (Tuesday, February 4, 2020 8:41 PM) > >>> +1 from my side. It doesn’t have dependencies on any other code, so > >>> it can’t break anything else neither. > > > > Jani Heikkinen (5 February 2020 06:42) > >> Why this is so important that we should get the exception & go in after > FF? > > > > Do we allow changes approved before feature freeze to get past the > > Coin hurdle, even if that happens after FF ? How much fixing of the > > change (if it turns out to have problems integrating) is acceptable, > > before we declare that it's no longer the change that was approved in time > ? > > > > In the present instance (modulo: I may have misunderstood some of > > what's going on), we have a change that's integrated in 5.15 but won't > > merge up to dev because dev has a platform 5.15 lacks, on which the > > change doesn't compile. This is blocking 5.15 -> dev merges in qtbase > > at present. Volker is trying to fix that in 5.15, so that the > > merge-up can go ahead. Either we revert the commit that introduced > > move-to-trash, to unblock merging, or we need to fix in 5.15 the build > > that's only done in dev. A revert means backing out of the feature, > > even though (IIUC) it works just fine in 5.15. > > > The change was indeed approved before FF, and the implementation is in > thanks to that; the public API with the unit test is not because it turned > out to > be a surprisingly annoying feature to test in such a way that it passes our > CI :( > > The world certainly doesn’t end if we don’t get this in, but OTOH it’s silly > to > have to wait with this until Qt 6. But this particular feature shouldn’t > block the > Alpha either; the testing of the release machinery, and the feedback we get > through Alpha to the new modules and the more significant additions in Qt > 5.15 isn’t invalidated by this being added after Alpha. > > But your call, Jani. If we don’t get it in, then I will revert the already > merged > changes since those internal implementations don’t have a public API. Ok, fair enough. Let's take this in Qt 5.15; it seems this shouldn't cause too much harm or delays. And let's not delay Alpha because of this even I do think we should have all new features & APIs in Alpha already. But I know public API will be changed after Alpha because of API review findings so it doesn't matter that much if simple API methods are added after the Alpha release as well br, Jani ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
https://codereview.qt-project.org/c/qt/qtbase/+/285791 > But ok otherwise. So +1-1=0. Interesting. Best regards, Timur. From: Development on behalf of Thiago Macieira Sent: Wednesday, February 5, 2020 7:43 PM To: development@qt-project.org Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote: > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira > > wrote: > > The correct signal for an error situation is errorOccurred, like in > > QLocalSocket and QProcess. > > Actually both QLocalSocket and QAbstractSocket renamed the "error()" > getter to keep using "error()" signal as opposed to many other Qt > modules "errorOccurred()" signals. Which is the opposite of QProcess and violates the naming convention. Signals are named after verbs in the past tense and properties & property getters are simple nouns. So "error" is the getter, "errorOccurred" is the signal. qprocess.h: #if QT_DEPRECATED_SINCE(5, 6) QT_DEPRECATED_X("Use QProcess::errorOccurred(QProcess::ProcessError) instead") void error(QProcess::ProcessError error); #endif void errorOccurred(QProcess::ProcessError error); -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On Wednesday, 5 February 2020 08:03:45 PST Shawn Rutledge wrote: > It defeats the purpose of deprecation to do that before you are ready. It’s > something to be done later, to verify that you really have gotten rid of > all uses of the old API. “Later” should not be as long a time as it has > been in the past (as in deprecating something only in documentation in 5.0, > and then waiting until 5.14 to deal with the consequences); but it also IMO > should not be treated as a P0 blocker issue hanging over our heads the > instant after deprecating something, to go and rewrite all uses in all > modules. It’s technical debt though. Deprecation should be done preferably at least one release after the replacement API became available. If that's not possible, in the same release. Deprecating without a replacement should only be done if there will be no replacement or if the API is actually harmful. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote: > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira > > wrote: > > The correct signal for an error situation is errorOccurred, like in > > QLocalSocket and QProcess. > > Actually both QLocalSocket and QAbstractSocket renamed the "error()" > getter to keep using "error()" signal as opposed to many other Qt > modules "errorOccurred()" signals. Which is the opposite of QProcess and violates the naming convention. Signals are named after verbs in the past tense and properties & property getters are simple nouns. So "error" is the getter, "errorOccurred" is the signal. qprocess.h: #if QT_DEPRECATED_SINCE(5, 6) QT_DEPRECATED_X("Use QProcess::errorOccurred(QProcess::ProcessError) instead") void error(QProcess::ProcessError error); #endif void errorOccurred(QProcess::ProcessError error); -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
Correct, to avoid breaking old connection syntax silently (with warnings not noticed in code). Now, please enumerate those many modules you are talking about? There are 4 classes in QtNetwork doing similar changes (not touching a tricky signal, but a getter) and I, as the maintainer of QtNetwork, prefer it this way. Best. From: Development on behalf of Alexander Akulich Sent: Wednesday, February 5, 2020 6:41 PM To: Thiago Macieira Cc: Qt development mailing list Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira wrote: > > The correct signal for an error situation is errorOccurred, like in > QLocalSocket and QProcess. Actually both QLocalSocket and QAbstractSocket renamed the "error()" getter to keep using "error()" signal as opposed to many other Qt modules "errorOccurred()" signals. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira wrote: > > The correct signal for an error situation is errorOccurred, like in > QLocalSocket and QProcess. Actually both QLocalSocket and QAbstractSocket renamed the "error()" getter to keep using "error()" signal as opposed to many other Qt modules "errorOccurred()" signals. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On Wed, Feb 5, 2020 at 7:29 PM Alexander Akulich wrote: > > On Wed, Feb 5, 2020 at 1:11 PM Ville Voutilainen > wrote: > > > > Isn't that an ABI break? > > Yep; this is what we're doing here (we're deprecating and sorting out > the API to break the ABI in Qt 6). (I thought that it is obvious, but it seems to be not the case, so:) I mean that we want to prepare and improve the API for Qt 6, so we need to add some signals and mark some others as deprecated. This is a well-known procedure and it is not an ABI breakage for a regular (e.g. not "no-deprecated") build. What I'm proposing to do is basically to apply for QAbstractSocket the same API changes as done in [1] for QProcess. [1] https://code.qt.io/cgit/qt/qtbase.git/commit/?id=4672e319e6dd0fbaa986e056e52dbb06d78fcfa5 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On Wed, Feb 5, 2020 at 1:11 PM Ville Voutilainen wrote: > > Isn't that an ABI break? Yep; this is what we're doing here (we're deprecating and sorting out the API to break the ABI in Qt 6). ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
It seems "feature freeze" != "API freeze" and the API review for 5.15 is still "to be done", so we still can raise the objection at the right time for Qt 5.15. The API consistency is one of the biggest advantages of Qt and I really hope that we won't stop caring about it. On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira wrote: > > On Wednesday, 5 February 2020 02:12:06 PST Alexander Akulich wrote: > > Oh, I'm sorry for the spam! You already renamed error() getter to > > sockerError() [1], so the issue is not relevant now. > > It's a bit unfortunate to see such diversity in the API. error() > > getter seems to be a convention in Qt. I thought that the same > > convention is to use '-ed' verbs in signal names. > > It is. The correct signal for an error situation is errorOccurred, like in > QLocalSocket and QProcess. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
> On 5 Feb 2020, at 16:31, Edward Welbourne wrote: > > Shawn Rutledge (5 February 2020 14:14) >> So I’m strongly in favor of continuing to do deprecations as long as >> possible. A deprecation is not something that can break existing >> functionality, so it’s no real risk as long as we’re sure we really >> want to deprecate it. > > A deprecation can break existing builds, for those who enable > warnings-are-errors. It defeats the purpose of deprecation to do that before you are ready. It’s something to be done later, to verify that you really have gotten rid of all uses of the old API. “Later” should not be as long a time as it has been in the past (as in deprecating something only in documentation in 5.0, and then waiting until 5.14 to deal with the consequences); but it also IMO should not be treated as a P0 blocker issue hanging over our heads the instant after deprecating something, to go and rewrite all uses in all modules. It’s technical debt though. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On Wednesday, 5 February 2020 02:12:06 PST Alexander Akulich wrote: > Oh, I'm sorry for the spam! You already renamed error() getter to > sockerError() [1], so the issue is not relevant now. > It's a bit unfortunate to see such diversity in the API. error() > getter seems to be a convention in Qt. I thought that the same > convention is to use '-ed' verbs in signal names. It is. The correct signal for an error situation is errorOccurred, like in QLocalSocket and QProcess. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
Shawn Rutledge (5 February 2020 14:14) > So I’m strongly in favor of continuing to do deprecations as long as > possible. A deprecation is not something that can break existing > functionality, so it’s no real risk as long as we’re sure we really > want to deprecate it. A deprecation can break existing builds, for those who enable warnings-are-errors. Consequently, in the API change review, reviewers need to be able to see all deprecations, in order to be able to raise objections to any that are going to cause pain. I am well aware of how being kept from Qt 6 work makes it hard to discover the deprecations that'll be needed in 5.15 to support that Qt 6 work, once we get to it - I spent much of the last fortnight frantically getting those deprecations (and some API consolidations I noticed in the process) sorted out, precisely because I understood feature freeze as a hard cut-off. Dealing with it as such gives everyone a clearer view of what we're doing. I accept that the final Qt 5 release is special - and agree that the usual "we do time-based, so your change that missed FF only has to wait half a year" isn't as true as it would be at other times - but we do need to have visibility for changes to the API - including deprecations - so that our API change reviews can do their job properly. That includes clients of an API getting a chance to object to a deprecation. So please be sure to comment on API change reviews if you even suspect you may be about to decide to deprecate things that haven't yet been sorted out before feature freeze. API change reviewers need to know about them. We seem to have some diversity of opinion on how hard a cut-off the feature freeze is meant to be: that's a topic we need to discuss and answer, if we're to have release processes we can trust. On the one hand, the need for predictability in our release process means we need to have deadlines and stick to them. On the other hand, various practicalities make it necessary to have some flexibility. I think we need to revisit the incomplete QUIP 11 and actually document which things cut off when. https://codereview.qt-project.org/c/meta/quips/+/228450 Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
> -Original Message- > From: Releasing On Behalf Of Jani > Heikkinen > Sent: Wednesday, 5 February 2020 6:37 AM > To: Lars Knoll ; Yulong Bai > Cc: Volker Hilsheimer ; Qt development mailing list > ; releas...@qt-project.org > Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is > in effect now > > Hi! > > Yeah, for me this seems to be quite low risky addition as well. Only concern > is > that we need to delay the Alpha release because of this late addition. We > have Alpha content in place already now and at least in theory we should > delay it until all new features are in... So adding 2 weeks delay to there > doesn't sound that nice to me at this point.; delays are usually causing > problems & unnecessary hassle later phases of releasing :( And taking this in > between Alpha and beta doesn't sound that well to me either; what is the > purpose of Alpha if there isn't all known features in... > > Why this is so important that we should get the exception & go in after FF? Hi Jani. - It's a vital part of creating a table in Qt Quick, and something that is non-trivial for a good chunk of users to implement themselves. - I think you and Lars have already said it's low risk, which is true. - I don't think this counts as justification, but.. it's been in the works for a while, and we really shouldn't delay it any longer. - I'm also confident we will be ready to merge it today. Cheers. > br, > Jani > > > From: Lars Knoll > Sent: Tuesday, February 4, 2020 3:50 PM > To: Yulong Bai > Cc: Jani Heikkinen; Qt development mailing list; releas...@qt-project.org; > Volker Hilsheimer > Subject: Re: [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect > now > > I’d be ok with extending the deadline for this one item until end of next > week. It shouldn’t be able to break other things as far as I can tell. > > But would like to hear Jani’s opinion as well. If he’s also ok go ahead, but > it > really needs to get approved and merged quickly. > > Cheers, > Lars > > On 4 Feb 2020, at 14:39, Yulong Bai > mailto:yulong@qt.io>> wrote: > > Hello, > > HeaderView is almost done but I just missed the feature-freeze. I will have it > ready by this Friday. > > So, is it OK for everybody that I merge it after the 5.15 feature freeze. It's > here https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/270170 > > br, > Yulong > Software Engineer > > From: Jani Heikkinen mailto:jani.heikki...@qt.io>> > Sent: 03 February 2020 06:35 > To: development@qt-project.org<mailto:development@qt-project.org> > mailto:development@qt-project.org>>; > releas...@qt-project.org<mailto:releas...@qt-project.org> project.org<mailto:releas...@qt-project.org>> > Subject: [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect now > > Hi all, > > Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' > anymore. Please update Qt 5.15 new features page > (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite > empty still... > > Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we can > get it > out already during this week. > > API review for Qt 5.15 will start soon as well. Please do reviews immediately > when available. > > br, > Jani Heikkinen > Release Manager > > ___ > Releasing mailing list > releas...@qt-project.org > https://lists.qt-project.org/listinfo/releasing ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On 5 Feb 2020, at 13:04, Jani Heikkinen mailto:jani.heikki...@qt.io>> wrote: We are doing time based releases so if new feature misses the deadline there will be next one coming after few months. It might be quite long time for unique feature but on the other hand it isn't really that long… It’s the end of the Qt 5 series, so time to the next Qt 5 release after this one is infinite (it won't happen at all). Users won’t switch to Qt 6 anytime soon. Missing functionality will hurt them more than usual. I’m not talking about pie-in-the-sky ideas, but features that are close to done and were promised for a long time already; and even more so, missing features that are blocking imminent releases of other modules that were promised, or already paid for. Failing to get all the deprecations in place for things we want to remove in Qt 6 will also hurt users a lot. So I think we need to be more flexible than usual about getting those in. And those of us who had real work to add features in 5.15 have not yet had time to work on the sort of Qt 6 things that could result in the need to add deprecations in 5.15. (And that will probably go on for a few more weeks, too.) If you argue against getting more deprecations in place in 5.15, then you are also implicitly arguing in favor of having more SC breaks in Qt 6. So I’m strongly in favor of continuing to do deprecations as long as possible. A deprecation is not something that can break existing functionality, so it’s no real risk as long as we’re sure we really want to deprecate it. The exact timing of the 5.15 release could even slip more than usual; what will it really matter? For once I think we should be concerned more about quality than timing. As long as we get 5.15.0 out within the first half of the year, we will satisfy our duty to the almighty #%#$% schedule. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
> -Original Message- > From: Eskil Abrahamsen Blomfeldt > Sent: keskiviikko 5. helmikuuta 2020 13.06 > To: Edward Welbourne ; Jani Heikkinen > ; Lars Knoll ; Volker Hilsheimer > > Cc: Qt development mailing list ; > releas...@qt-project.org > Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is > in effect now > > > On 05.02.2020 11:50, Edward Welbourne wrote: > > Jani Heikkinen (5 February 2020 06:42) > >> Why this is so important that we should get the exception & go in after > FF? > > Do we allow changes approved before feature freeze to get past the > > Coin hurdle, even if that happens after FF ? How much fixing of the > > change (if it turns out to have problems integrating) is acceptable, > > before we declare that it's no longer the change that was approved in time > ? > > > If the change is ready and approved by the time of feature freeze and only > delayed by CI problems, failures from other changes in a batch, or the > awkwardness of our dependency structure, I think it has to be acceptable to > merge after the freeze. Otherwise feature freeze becomes a lottery where > the features in a given release is based mostly on chance. By default we shouldn't put any new features in after FF, not even those which were approved early enough. Not respecting the freeze date was one of biggest reasons why we failed to keep the release schedule with earlier releases. And after we started to be much tighter with the freeze we have been much better to keep the schedules as well... > The slack to accommodate these intrinsic delays need to be in the release > plan in my opinion, and not in each developer's individual plan for merging > their changes. I have to disagree. Everyone knows that there is flakiness/problems in integrations and so on changes has to be ready early enough so that there is still time to pass the CI. That's why FF date is agreed & informed quite early & there is several heads-up telling it is coming closer... We are doing time based releases so if new feature misses the deadline there will be next one coming after few months. It might be quite long time for unique feature but on the other hand it isn't really that long... Our goal is to cut the schedule between FF and final release, not reserving more time there. Ok, currently there is of course some buffer in; Release plans are based on previous releases and realized schedules there. But we should be able to develop our ways of working & our release systems so that we can make that time much shorter. That way we could get more time to develop new features. br, Jani ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
> -Original Message- > From: Volker Hilsheimer > Sent: keskiviikko 5. helmikuuta 2020 13.10 > To: Edward Welbourne > Cc: Jani Heikkinen ; Lars Knoll ; > development@qt-project.org; releas...@qt-project.org > Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is > in effect now > > > On 5 Feb 2020, at 11:50, Edward Welbourne > wrote: > > > > On 4 Feb 2020, at 16:56, Volker Hilsheimer > wrote: > >>>> I’ve been struggling a bit more than expected with getting the > >>>> implementation of "move a file or directory to the trash" pass CI. > >>>> It’s a popular feature request: > >>>> > >>>> https://bugreports.qt.io/browse/QTBUG-47703 > >>>> > >>>> The basic implementation and private APIs have been in for a bit, > >>>> but required a bit of follow-up, which delayed the merging of the > >>>> commit that adds the public API in: > >>>> > >>>> https://codereview.qt-project.org/c/qt/qtbase/+/287373 > > > > Lars Knoll (Tuesday, February 4, 2020 8:41 PM) > >>> +1 from my side. It doesn’t have dependencies on any other code, so > >>> it can’t break anything else neither. > > > > Jani Heikkinen (5 February 2020 06:42) > >> Why this is so important that we should get the exception & go in after > FF? > > > > Do we allow changes approved before feature freeze to get past the > > Coin hurdle, even if that happens after FF ? How much fixing of the > > change (if it turns out to have problems integrating) is acceptable, > > before we declare that it's no longer the change that was approved in time > ? > > > > In the present instance (modulo: I may have misunderstood some of > > what's going on), we have a change that's integrated in 5.15 but won't > > merge up to dev because dev has a platform 5.15 lacks, on which the > > change doesn't compile. This is blocking 5.15 -> dev merges in qtbase > > at present. Volker is trying to fix that in 5.15, so that the > > merge-up can go ahead. Either we revert the commit that introduced > > move-to-trash, to unblock merging, or we need to fix in 5.15 the build > > that's only done in dev. A revert means backing out of the feature, > > even though (IIUC) it works just fine in 5.15. > > > The change was indeed approved before FF, and the implementation is in > thanks to that; the public API with the unit test is not because it turned > out to > be a surprisingly annoying feature to test in such a way that it passes our > CI :( > > The world certainly doesn’t end if we don’t get this in, but OTOH it’s silly > to > have to wait with this until Qt 6. But this particular feature shouldn’t > block the > Alpha either; the testing of the release machinery, and the feedback we get > through Alpha to the new modules and the more significant additions in Qt > 5.15 isn’t invalidated by this being added after Alpha. > > But your call, Jani. If we don’t get it in, then I will revert the already > merged > changes since those internal implementations don’t have a public API. Ok, fair enough. Let's take this in Qt 5.15; it seems this shouldn't cause too much harm or delays. And let's not delay Alpha because of this even I do think we should have all new features & APIs in Alpha already. But I know public API will be changed after Alpha because of API review findings so it doesn't matter that much if simple API methods are added after the Alpha release as well br, Jani ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
> On 5 Feb 2020, at 11:50, Edward Welbourne wrote: > > On 4 Feb 2020, at 16:56, Volker Hilsheimer wrote: I’ve been struggling a bit more than expected with getting the implementation of "move a file or directory to the trash" pass CI. It’s a popular feature request: https://bugreports.qt.io/browse/QTBUG-47703 The basic implementation and private APIs have been in for a bit, but required a bit of follow-up, which delayed the merging of the commit that adds the public API in: https://codereview.qt-project.org/c/qt/qtbase/+/287373 > > Lars Knoll (Tuesday, February 4, 2020 8:41 PM) >>> +1 from my side. It doesn’t have dependencies on any other code, so >>> it can’t break anything else neither. > > Jani Heikkinen (5 February 2020 06:42) >> Why this is so important that we should get the exception & go in after FF? > > Do we allow changes approved before feature freeze to get past the Coin > hurdle, even if that happens after FF ? How much fixing of the change > (if it turns out to have problems integrating) is acceptable, before we > declare that it's no longer the change that was approved in time ? > > In the present instance (modulo: I may have misunderstood some of what's > going on), we have a change that's integrated in 5.15 but won't merge up > to dev because dev has a platform 5.15 lacks, on which the change > doesn't compile. This is blocking 5.15 -> dev merges in qtbase at > present. Volker is trying to fix that in 5.15, so that the merge-up can > go ahead. Either we revert the commit that introduced move-to-trash, to > unblock merging, or we need to fix in 5.15 the build that's only done in > dev. A revert means backing out of the feature, even though (IIUC) it > works just fine in 5.15. The change was indeed approved before FF, and the implementation is in thanks to that; the public API with the unit test is not because it turned out to be a surprisingly annoying feature to test in such a way that it passes our CI :( The world certainly doesn’t end if we don’t get this in, but OTOH it’s silly to have to wait with this until Qt 6. But this particular feature shouldn’t block the Alpha either; the testing of the release machinery, and the feedback we get through Alpha to the new modules and the more significant additions in Qt 5.15 isn’t invalidated by this being added after Alpha. But your call, Jani. If we don’t get it in, then I will revert the already merged changes since those internal implementations don’t have a public API. That the change that passed CI for 5.15 blocks the merge to dev is not related to FF, but because we are testing different platforms in CI for dev than we do for 5.15. The follow-up that fixes the build for that merge is already in 5.15, and the merge needs to be updated to include those changes. Liang knows about that. Cheers, Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On 05.02.2020 11:50, Edward Welbourne wrote: > Jani Heikkinen (5 February 2020 06:42) >> Why this is so important that we should get the exception & go in after FF? > Do we allow changes approved before feature freeze to get past the Coin > hurdle, even if that happens after FF ? How much fixing of the change > (if it turns out to have problems integrating) is acceptable, before we > declare that it's no longer the change that was approved in time ? If the change is ready and approved by the time of feature freeze and only delayed by CI problems, failures from other changes in a batch, or the awkwardness of our dependency structure, I think it has to be acceptable to merge after the freeze. Otherwise feature freeze becomes a lottery where the features in a given release is based mostly on chance. The slack to accommodate these intrinsic delays need to be in the release plan in my opinion, and not in each developer's individual plan for merging their changes. If it turns out the change cannot be merged as-is and needs additional fixing, I think it should be addressed as any other change that doesn't match the conditions above: on a case-by-case basis, considering value vs. risk in each case. In the particular case you mention, I think we should fix the issues with the feature in 5.15 rather than revert it. The reason we have several months between freeze and release is so that we have time for stabilization work such as this. -- Eskil Abrahamsen Blomfeldt Senior Manager, Graphics The Qt Company Sandakerveien 116 0484, Oslo, Norway eskil.abrahamsen-blomfe...@qt.io +47 938 85 836 http://qt.io https://twitter.com/eskilblomfeldt The Future is Written with Qt ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On 4 Feb 2020, at 16:56, Volker Hilsheimer wrote: >>> I’ve been struggling a bit more than expected with getting the >>> implementation of "move a file or directory to the trash" pass >>> CI. It’s a popular feature request: >>> >>> https://bugreports.qt.io/browse/QTBUG-47703 >>> >>> The basic implementation and private APIs have been in for a bit, >>> but required a bit of follow-up, which delayed the merging of the >>> commit that adds the public API in: >>> >>> https://codereview.qt-project.org/c/qt/qtbase/+/287373 Lars Knoll (Tuesday, February 4, 2020 8:41 PM) >> +1 from my side. It doesn’t have dependencies on any other code, so >> it can’t break anything else neither. Jani Heikkinen (5 February 2020 06:42) > Why this is so important that we should get the exception & go in after FF? Do we allow changes approved before feature freeze to get past the Coin hurdle, even if that happens after FF ? How much fixing of the change (if it turns out to have problems integrating) is acceptable, before we declare that it's no longer the change that was approved in time ? In the present instance (modulo: I may have misunderstood some of what's going on), we have a change that's integrated in 5.15 but won't merge up to dev because dev has a platform 5.15 lacks, on which the change doesn't compile. This is blocking 5.15 -> dev merges in qtbase at present. Volker is trying to fix that in 5.15, so that the merge-up can go ahead. Either we revert the commit that introduced move-to-trash, to unblock merging, or we need to fix in 5.15 the build that's only done in dev. A revert means backing out of the feature, even though (IIUC) it works just fine in 5.15. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
There was already a patch which did this, for the getter: https://codereview.qt-project.org/c/qt/qtbase/+/286089 Fra: Development på vegne av Alexander Akulich Sendt: Wednesday, February 5, 2020 11:04:35 AM Til: Jani Heikkinen Kopi: Qt development mailing list Emne: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now What I'm talking about is to repeat [1] for QAbstractSocket [2] as a last-minute change for Qt 5.15. If such a patch is not acceptable for 5.15, is it still acceptable for Qt 6 (in terms of Qt 5.15/6.0 compatibility policy)? I'm going to prepare the patch right now, whether it 'll be accepted or not. (I hope and expect it to be a small change that is not sad to drop) [1] https://code.qt.io/cgit/qt/qtbase.git/commit/?id=4672e319e6dd0fbaa986e056e52dbb06d78fcfa5 [2] https://doc.qt.io/qt-5/qabstractsocket.html#error-1 On Wed, Feb 5, 2020 at 12:42 PM Alexander Akulich wrote: > > Hi all, > > does the 5.15 feature freeze mean that we can not adjust signal names > anymore? IIRC it was said that "deprecated-free" code for Qt 5.15 > will/should be compatible with Qt 6. > > IIRC there was an intention to rename > QAbstractSocket::error(SocketError) signal to errorOccured() to align > it with the other signals and to remove the overload of > QAbstractSocket::error() getter, so the API becomes a bit more > developer-friendly. > I thought that it was done, but it seems to be not the case. I can > prepare and submit a patch in a few hours if it is still applicable > for 5.15. > > On Wed, Feb 5, 2020 at 8:43 AM Jani Heikkinen wrote: > > > > Hi! > > > > For this one my reply is similar :D > > > > Why this is so important that we should get the exception & go in after FF? > > We need to delay the Alpha release because of this late addition if we > > agree to take this in. It seems this shouldn't cause that big delay but you > > never know... And taking this in between Alpha and beta doesn't sound that > > well to me either; as written before all known features should be in > > Alpha... > > > > br, > > Jani > > > > > > > > From: Lars Knoll > > Sent: Tuesday, February 4, 2020 8:41 PM > > To: Volker Hilsheimer > > Cc: Jani Heikkinen; Qt development mailing list; releas...@qt-project.org > > Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is > > in effect now > > > > > On 4 Feb 2020, at 16:56, Volker Hilsheimer > > > wrote: > > > > > >> On 3 Feb 2020, at 06:35, Jani Heikkinen wrote: > > >> > > >> Hi all, > > >> > > >> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' > > >> anymore. Please update Qt 5.15 new features page > > >> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite > > >> empty still... > > >> > > >> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we > > >> can get it out already during this week. > > >> > > >> API review for Qt 5.15 will start soon as well. Please do reviews > > >> immediately when available. > > >> > > >> br, > > >> Jani Heikkinen > > > > > > > > > I’ve been struggling a bit more than expected with getting the > > > implementation of "move a file or directory to the trash" pass CI. It’s a > > > popular feature request: > > > > > > https://bugreports.qt.io/browse/QTBUG-47703 > > > > > > The basic implementation and private APIs have been in for a bit, but > > > required a bit of follow-up, which delayed the merging of the commit that > > > adds the public API in: > > > > > > https://codereview.qt-project.org/c/qt/qtbase/+/287373 > > > > +1 from my side. It doesn’t have dependencies on any other code, so it > > can’t break anything else neither. > > > > Cheers, > > Lars > > > > ___ > > Development mailing list > > Development@qt-project.org > > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development From: Alexander Akulich<mailto:akulichalexan...@gmail.com> Sent: onsdag 5. februar 2020 11:07 Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now What I'm talking about is to repeat [1] for QAbstractSocket [2] as a last-minute change for Qt 5
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
Oh, I'm sorry for the spam! You already renamed error() getter to sockerError() [1], so the issue is not relevant now. It's a bit unfortunate to see such diversity in the API. error() getter seems to be a convention in Qt. I thought that the same convention is to use '-ed' verbs in signal names. [1] https://code.qt.io/cgit/qt/qtbase.git/commit/?h=5.15=94b3dd77f29a00ebbd1efdc66d75f57e1c75b152 On Wed, Feb 5, 2020 at 1:04 PM Alexander Akulich wrote: > > What I'm talking about is to repeat [1] for QAbstractSocket [2] as a > last-minute change for Qt 5.15. > If such a patch is not acceptable for 5.15, is it still acceptable for > Qt 6 (in terms of Qt 5.15/6.0 compatibility policy)? > > I'm going to prepare the patch right now, whether it 'll be accepted > or not. (I hope and expect it to be a small change that is not sad to > drop) > > [1] > https://code.qt.io/cgit/qt/qtbase.git/commit/?id=4672e319e6dd0fbaa986e056e52dbb06d78fcfa5 > [2] https://doc.qt.io/qt-5/qabstractsocket.html#error-1 > > On Wed, Feb 5, 2020 at 12:42 PM Alexander Akulich > wrote: > > > > Hi all, > > > > does the 5.15 feature freeze mean that we can not adjust signal names > > anymore? IIRC it was said that "deprecated-free" code for Qt 5.15 > > will/should be compatible with Qt 6. > > > > IIRC there was an intention to rename > > QAbstractSocket::error(SocketError) signal to errorOccured() to align > > it with the other signals and to remove the overload of > > QAbstractSocket::error() getter, so the API becomes a bit more > > developer-friendly. > > I thought that it was done, but it seems to be not the case. I can > > prepare and submit a patch in a few hours if it is still applicable > > for 5.15. > > > > On Wed, Feb 5, 2020 at 8:43 AM Jani Heikkinen wrote: > > > > > > Hi! > > > > > > For this one my reply is similar :D > > > > > > Why this is so important that we should get the exception & go in after > > > FF? We need to delay the Alpha release because of this late addition if > > > we agree to take this in. It seems this shouldn't cause that big delay > > > but you never know... And taking this in between Alpha and beta doesn't > > > sound that well to me either; as written before all known features should > > > be in Alpha... > > > > > > br, > > > Jani > > > > > > > > > ____ > > > From: Lars Knoll > > > Sent: Tuesday, February 4, 2020 8:41 PM > > > To: Volker Hilsheimer > > > Cc: Jani Heikkinen; Qt development mailing list; releas...@qt-project.org > > > Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze > > > is in effect now > > > > > > > On 4 Feb 2020, at 16:56, Volker Hilsheimer > > > > wrote: > > > > > > > >> On 3 Feb 2020, at 06:35, Jani Heikkinen wrote: > > > >> > > > >> Hi all, > > > >> > > > >> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' > > > >> anymore. Please update Qt 5.15 new features page > > > >> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite > > > >> empty still... > > > >> > > > >> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if > > > >> we can get it out already during this week. > > > >> > > > >> API review for Qt 5.15 will start soon as well. Please do reviews > > > >> immediately when available. > > > >> > > > >> br, > > > >> Jani Heikkinen > > > > > > > > > > > > I’ve been struggling a bit more than expected with getting the > > > > implementation of "move a file or directory to the trash" pass CI. It’s > > > > a popular feature request: > > > > > > > > https://bugreports.qt.io/browse/QTBUG-47703 > > > > > > > > The basic implementation and private APIs have been in for a bit, but > > > > required a bit of follow-up, which delayed the merging of the commit > > > > that adds the public API in: > > > > > > > > https://codereview.qt-project.org/c/qt/qtbase/+/287373 > > > > > > +1 from my side. It doesn’t have dependencies on any other code, so it > > > can’t break anything else neither. > > > > > > Cheers, > > > Lars > > > > > > ___ > > > Development mailing list > > > Development@qt-project.org > > > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On Wed, 5 Feb 2020 at 11:44, Alexander Akulich wrote: > > Hi all, > > does the 5.15 feature freeze mean that we can not adjust signal names > anymore? IIRC it was said that "deprecated-free" code for Qt 5.15 > will/should be compatible with Qt 6. > > IIRC there was an intention to rename > QAbstractSocket::error(SocketError) signal to errorOccured() to align > it with the other signals and to remove the overload of > QAbstractSocket::error() getter, so the API becomes a bit more > developer-friendly. > I thought that it was done, but it seems to be not the case. I can > prepare and submit a patch in a few hours if it is still applicable > for 5.15. Isn't that an ABI break? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
What I'm talking about is to repeat [1] for QAbstractSocket [2] as a last-minute change for Qt 5.15. If such a patch is not acceptable for 5.15, is it still acceptable for Qt 6 (in terms of Qt 5.15/6.0 compatibility policy)? I'm going to prepare the patch right now, whether it 'll be accepted or not. (I hope and expect it to be a small change that is not sad to drop) [1] https://code.qt.io/cgit/qt/qtbase.git/commit/?id=4672e319e6dd0fbaa986e056e52dbb06d78fcfa5 [2] https://doc.qt.io/qt-5/qabstractsocket.html#error-1 On Wed, Feb 5, 2020 at 12:42 PM Alexander Akulich wrote: > > Hi all, > > does the 5.15 feature freeze mean that we can not adjust signal names > anymore? IIRC it was said that "deprecated-free" code for Qt 5.15 > will/should be compatible with Qt 6. > > IIRC there was an intention to rename > QAbstractSocket::error(SocketError) signal to errorOccured() to align > it with the other signals and to remove the overload of > QAbstractSocket::error() getter, so the API becomes a bit more > developer-friendly. > I thought that it was done, but it seems to be not the case. I can > prepare and submit a patch in a few hours if it is still applicable > for 5.15. > > On Wed, Feb 5, 2020 at 8:43 AM Jani Heikkinen wrote: > > > > Hi! > > > > For this one my reply is similar :D > > > > Why this is so important that we should get the exception & go in after FF? > > We need to delay the Alpha release because of this late addition if we > > agree to take this in. It seems this shouldn't cause that big delay but you > > never know... And taking this in between Alpha and beta doesn't sound that > > well to me either; as written before all known features should be in > > Alpha... > > > > br, > > Jani > > > > > > > > From: Lars Knoll > > Sent: Tuesday, February 4, 2020 8:41 PM > > To: Volker Hilsheimer > > Cc: Jani Heikkinen; Qt development mailing list; releas...@qt-project.org > > Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is > > in effect now > > > > > On 4 Feb 2020, at 16:56, Volker Hilsheimer > > > wrote: > > > > > >> On 3 Feb 2020, at 06:35, Jani Heikkinen wrote: > > >> > > >> Hi all, > > >> > > >> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' > > >> anymore. Please update Qt 5.15 new features page > > >> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite > > >> empty still... > > >> > > >> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we > > >> can get it out already during this week. > > >> > > >> API review for Qt 5.15 will start soon as well. Please do reviews > > >> immediately when available. > > >> > > >> br, > > >> Jani Heikkinen > > > > > > > > > I’ve been struggling a bit more than expected with getting the > > > implementation of "move a file or directory to the trash" pass CI. It’s a > > > popular feature request: > > > > > > https://bugreports.qt.io/browse/QTBUG-47703 > > > > > > The basic implementation and private APIs have been in for a bit, but > > > required a bit of follow-up, which delayed the merging of the commit that > > > adds the public API in: > > > > > > https://codereview.qt-project.org/c/qt/qtbase/+/287373 > > > > +1 from my side. It doesn’t have dependencies on any other code, so it > > can’t break anything else neither. > > > > Cheers, > > Lars > > > > ___ > > Development mailing list > > Development@qt-project.org > > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
Hi all, does the 5.15 feature freeze mean that we can not adjust signal names anymore? IIRC it was said that "deprecated-free" code for Qt 5.15 will/should be compatible with Qt 6. IIRC there was an intention to rename QAbstractSocket::error(SocketError) signal to errorOccured() to align it with the other signals and to remove the overload of QAbstractSocket::error() getter, so the API becomes a bit more developer-friendly. I thought that it was done, but it seems to be not the case. I can prepare and submit a patch in a few hours if it is still applicable for 5.15. On Wed, Feb 5, 2020 at 8:43 AM Jani Heikkinen wrote: > > Hi! > > For this one my reply is similar :D > > Why this is so important that we should get the exception & go in after FF? > We need to delay the Alpha release because of this late addition if we agree > to take this in. It seems this shouldn't cause that big delay but you never > know... And taking this in between Alpha and beta doesn't sound that well to > me either; as written before all known features should be in Alpha... > > br, > Jani > > > > From: Lars Knoll > Sent: Tuesday, February 4, 2020 8:41 PM > To: Volker Hilsheimer > Cc: Jani Heikkinen; Qt development mailing list; releas...@qt-project.org > Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is > in effect now > > > On 4 Feb 2020, at 16:56, Volker Hilsheimer wrote: > > > >> On 3 Feb 2020, at 06:35, Jani Heikkinen wrote: > >> > >> Hi all, > >> > >> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' > >> anymore. Please update Qt 5.15 new features page > >> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite > >> empty still... > >> > >> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we > >> can get it out already during this week. > >> > >> API review for Qt 5.15 will start soon as well. Please do reviews > >> immediately when available. > >> > >> br, > >> Jani Heikkinen > > > > > > I’ve been struggling a bit more than expected with getting the > > implementation of "move a file or directory to the trash" pass CI. It’s a > > popular feature request: > > > > https://bugreports.qt.io/browse/QTBUG-47703 > > > > The basic implementation and private APIs have been in for a bit, but > > required a bit of follow-up, which delayed the merging of the commit that > > adds the public API in: > > > > https://codereview.qt-project.org/c/qt/qtbase/+/287373 > > +1 from my side. It doesn’t have dependencies on any other code, so it can’t > break anything else neither. > > Cheers, > Lars > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
Hi! For this one my reply is similar :D Why this is so important that we should get the exception & go in after FF? We need to delay the Alpha release because of this late addition if we agree to take this in. It seems this shouldn't cause that big delay but you never know... And taking this in between Alpha and beta doesn't sound that well to me either; as written before all known features should be in Alpha... br, Jani From: Lars Knoll Sent: Tuesday, February 4, 2020 8:41 PM To: Volker Hilsheimer Cc: Jani Heikkinen; Qt development mailing list; releas...@qt-project.org Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect now > On 4 Feb 2020, at 16:56, Volker Hilsheimer wrote: > >> On 3 Feb 2020, at 06:35, Jani Heikkinen wrote: >> >> Hi all, >> >> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' >> anymore. Please update Qt 5.15 new features page >> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite empty >> still... >> >> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we can >> get it out already during this week. >> >> API review for Qt 5.15 will start soon as well. Please do reviews >> immediately when available. >> >> br, >> Jani Heikkinen > > > I’ve been struggling a bit more than expected with getting the implementation > of "move a file or directory to the trash" pass CI. It’s a popular feature > request: > > https://bugreports.qt.io/browse/QTBUG-47703 > > The basic implementation and private APIs have been in for a bit, but > required a bit of follow-up, which delayed the merging of the commit that > adds the public API in: > > https://codereview.qt-project.org/c/qt/qtbase/+/287373 +1 from my side. It doesn’t have dependencies on any other code, so it can’t break anything else neither. Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
> On 4 Feb 2020, at 16:56, Volker Hilsheimer wrote: > >> On 3 Feb 2020, at 06:35, Jani Heikkinen wrote: >> >> Hi all, >> >> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' >> anymore. Please update Qt 5.15 new features page >> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite empty >> still... >> >> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we can >> get it out already during this week. >> >> API review for Qt 5.15 will start soon as well. Please do reviews >> immediately when available. >> >> br, >> Jani Heikkinen > > > I’ve been struggling a bit more than expected with getting the implementation > of "move a file or directory to the trash" pass CI. It’s a popular feature > request: > > https://bugreports.qt.io/browse/QTBUG-47703 > > The basic implementation and private APIs have been in for a bit, but > required a bit of follow-up, which delayed the merging of the commit that > adds the public API in: > > https://codereview.qt-project.org/c/qt/qtbase/+/287373 +1 from my side. It doesn’t have dependencies on any other code, so it can’t break anything else neither. Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development