> -----Original Message----- > From: Jani Heikkinen > I have to disagree a bit: Alpha and beta phases are important and schedule > for FF > (and Alpha) as well. But for beta and RC we really don't need it: After API > review > is done we will enter in beta phase (and at this same time beta1 is > released). And > we should release RC when all blockers are fixed. If we schedule the RC > beforehand it seems to affect how developers are prioritizing their work. And > that's why I think we shouldn't even estimate when the RC is going to be > happen: It is released when we are ready for it. > > So I think the way to proceed with this should be like Lars proposed: > - Snapshot packages from the dev branch > - FF and branching occur together and packages are getting the 'alpha' tag > - Agree that we should start with the API review immediately. > - Beta once API review is done. Lets agree the 'Done' properly to get it > clear for > everyone. I already tried to start discussion about it in http://lists.qt- > > project.org/pipermail/development/2018-March/032338.html
Developers get a window of time between Alpha and Beta to do finishing work on the API. This may include the API review or self-motivated changes. The review can only finish once the changes have finished. The above suggestion shrinks the window of opportunity for proper API down to the time of the review. That's not sufficient. In fact, that's not even a time based release process. At alpha time people focus on feature completion and API is not the absolute primary focus. That focus shifts after Alpha. Not setting a Beta target makes it impossible to plan post-alpha changes and as a matter of fact, it removes the deadline to finish up the official reviews too. Lars' suggestion does not imply that the only API changes after Alpha are the review changes. Lars also does not state that we shouldn't set a target date for beta. It may even mean that it shifts out when the review is not done. In summary let's not shift away from a time-based release process to a "when it's done" process (even for Beta or RC). It is hard to predict a time for you and it's equally hard for the engineers to stick to time. We all must shoulder a burden. When the time slips then it slips but there must be a min time frame given in advance for each release step. Then we can plan work. -- Alex _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
