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.
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
>> Yes we do.
>> Alpha means feature complete, asking for feedback on the API and new
>> 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?
> Development mailing list
Development mailing list