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.hausm...@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.blas...@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@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
