[Development] Qt 5.15 API review

[Volker Hilsheimer]

> On 10 Mar 2020, at 14:21, Jani Heikkinen <jani.heikkinen at qt.io> wrote:
> 
>> -----Original Message-----
>> From: Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>
>> Sent: tiistai 10. maaliskuuta 2020 14.48
>> To: Jani Heikkinen <jani.heikkinen at qt.io>
>> Cc: Qt development mailing list <development at qt-project.org>
>> Subject: Re: [Development] Qt 5.15 API review
>> 
>> Il 10/03/20 13:45, Jani Heikkinen ha scritto:
>>> We haven't been blocking Beta (n) lately because of ongoing API review.
>> Earlier when there were only one beta we did that. After we started to
>> deliver several beta releases we stopped to block betas because of not
>> finalized API review.
>>> 
>>> And I think that is correct way to do this; It is better to start publishing beta
>> releases as soon as possible instead of waiting until API review is complete
>> 
>> But then, what's the difference between the alpha releases and the beta
>> releases?
>> 
> 
> That is actually really good question especially now when we are delivering binaries also with Alpha release.
> 
> I see that Alpha is a milestone to show what new we get in at FF. And Alpha should be out really soon after feature freeze and it is most important to get src packages out. Binaries are extra and some new modules can be missing from possible binary packages. Alpha is also a checkpoint to see that our releasing machinery will work.
> 
> And Beta1 starts beta phase where we should have all modules in builds & packages. But Beta1 can be still quite unfinished; target is to finalize release during beta phase as long as we are ready for RC. 
> 
> Couple of years ago I even proposed that we should stop doing Alpha and beta releases and just deliver snapshots until we are ready for RC. But that didn't get that much support at that time...
> 
> br,
> Jani


We discussed that at the contributors summit [1]) that API reviews should be part of the code review, not of the last-stage header review.

[1] https://wiki.qt.io/Qt_Contributors_Summit_2019_-_API_Review_Process

No follow up on this discussion yet.


But either way, I think having milestones and corresponding releases is useful. Perhaps we have some statistics on whether calling it “beta" makes people that don’t live on the bleeding edge to try things out.

In my mind,


Feature freeze != API freeze != header freeze.


Feature freeze: all the new things are in, let’s get some feedback from users - to the API, the packaging machinery, and installation process.

API freeze: based on the feedback we made the APIs as good as we could.

Header freeze: we have reviewed that none of the changes have *technical* side effects (such as breaking binary compatibility or source compatibility, such as changes to includes in headers).


Having an Alpha release after feature freeze, and starting with betas after API freeze, seems sensible. The header review can continue beyond that to confirm that we haven’t broken any of the technical commitments we are making as a project.


Volker