[Development] Qt 5.12 schedule proposal & proposal for release process change

Jani Heikkinen jani.heikkinen at qt.io
Mon Apr 16 11:35:28 CEST 2018


Hi!

Keeping release tags is OK for me. Motivation behind my proposal was to stop planning other release dates than FF & final target. Currently we are trying to estimate also alpha, beta and RC release dates and it seems to cause some delays for us: persons aren't fixing blocker issues or doing the test because it seems there is a time to do that later (because e.g RC date is planned to be after a month). So if the way to go is to do these "releases" immediately when ready it might help us to get fixes in earlier and so on also get releases out quicker...

But this change doesn't meant we need to stop calling those releases as Alpha or Betas so we can continue labeling those as earlier. 

br,
Jani


> -----Original Message-----
> From: Development <development-bounces+jani.heikkinen=qt.io at qt-
> project.org> On Behalf Of Lars Knoll
> Sent: maanantai 16. huhtikuuta 2018 10.03
> To: Simon Hausmann <Simon.Hausmann at qt.io>
> Cc: Qt development mailing list <development at qt-project.org>
> Subject: Re: [Development] Qt 5.12 schedule proposal & proposal for release
> process change
> 
> Hi,
> 
> From a releasing perspective I agree that the set we should update our
> packages often. We should also stop delivering source only alpha packages,
> and have binaries from the get go.
> 
> But from a user perspective, I agree that it's good and important to put a
> name to those releases so people know what to expect from them.
> Snapshots as long as the packages are created from the dev branch, then
> alpha, beta, RC and final. We could discuss whether we need the alpha label,
> or whether we can go directly to beta, but I believe that we do need the
> other tags.
> 
> But I do agree with releasing packages as often as possible, and we should
> have them already before FF from the dev branch (if possible).
> 
> So I’d propose to have our packages updated often. But we do keep the
> ‘snapshot’, ‘alpha’, ‘beta’ and ‘RC’ tags.
> 
> - 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
> - RC once we have the release branch and all currently known blockers are
> fixed
> 
> That should be pretty close to what Jani described, only that we keep the
> tags for our users.
> 
> Cheers,
> Lars
> 
> > On 16 Apr 2018, at 08:43, Simon Hausmann <Simon.Hausmann at qt.io>
> wrote:
> >
> > Hi,
> >
> > Same here. At first this seemed like a good idea, but it becomes awkward
> when you look at it from the dev workflow point of view: After fixing a bug,
> what is the fix version? Reported in snapshot-24062918 and fixed in
> snapshot-14072918? That sounds like it would create a mess in JIRA.
> >
> > Unless of course the task of assigning the fix version field was automated.
> >
> > Simon
> >
> > On 16. Apr 2018, at 08:12, Alex Blasche <alexander.blasche at qt.io> wrote:
> >
> >>> -----Original Message-----
> >>>> On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote:
> >>>> And at this same time I want to propose that we stop delivering
> >>>> alpha or beta releases and just do snapshots instead. Publishing
> >>>> regular snapshots should be done until we are ready for RC. That
> >>>> because I don't see that much need for those anymore. Those are
> >>>> nowadays kind of milestones and in my opinion makes whole process a
> >>>> bit unclear/difficult (we don't have very good definitions for
> >>>> Alpha and Beta
> >>> releases).
> >>>
> >>> Yes we do.
> >>>
> >>> Alpha means feature complete, asking for feedback on the API and new
> >>> functionality.
> >>>
> >>> Beta means implementation complete, asking for feedback on the
> >>> quality of the implementation, seeking bugs and regressions to be fixed.
> >>>
> >>> RC means we've fixed everything we knew.
> >>
> >> I wholeheartedly agree with Thiago. The distinction may not make a
> difference from the release team perspective but it makes a world of
> difference for developers (who have different limitations for each step) and
> the world as they can decide how bleeding edge the code is that they want
> to test.
> >>
> >> I have a problem with the motivation behind this suggestion too (don't
> understand it). The naming makes no difference for you as release manager
> (afaict just a label). Why suggesting it aka what do you want to gain by doing
> snapshots only?
> >> --
> >> Alex
> >>
> >> _______________________________________________
> >> Development mailing list
> >> Development at qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/development
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



More information about the Development mailing list