[Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Jani Heikkinen]

> -----Original Message-----
> From: Volker Hilsheimer <volker.hilsheimer at qt.io>
> Sent: keskiviikko 5. helmikuuta 2020 13.10
> To: Edward Welbourne <edward.welbourne at qt.io>
> Cc: Jani Heikkinen <jani.heikkinen at qt.io>; Lars Knoll <lars.knoll at qt.io>;
> development at qt-project.org; releasing at 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 <edward.welbourne at qt.io>
> wrote:
> >
> > On 4 Feb 2020, at 16:56, Volker Hilsheimer <volker.hilsheimer at qt.io>
> 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