[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: 2 kirigami fixes for a point release
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2020-02-17 7:52:50
Message-ID: CA+XidOHTh+0GWjvQe2mwd5gqWAZZgGtu6b-o3BCj1dDscFdoxQ () mail ! gmail ! com
[Download RAW message or body]

On Mon, Feb 17, 2020 at 4:42 AM David Edmundson
<david@davidedmundson.co.uk> wrote:
>
> > My point above was that the version you decide to freeze on should
> > only be the version you depend on during development.
> > The version you depend on when you release will be the next release of
> > Frameworks (so by freezing on 5.66 for development, it should have had
> > a release-day dependency of 5.67)
> >
> > The release of Plasma should then take place shortly after the
> > Frameworks version you have a release-day dependency on.
> >
>
> Just to clarify the current policy is:
>  - frameworks release 5.XX
>  - plasma beta
>  - frameworks release 5.XX+1
>  - plasma final
>
> Where 5.XX is the required version for Plasma. We set it as a dep,
> just after it gets released.
> We've had issues in the past, especially before frameworks had that
> 2nd Saturday of the month policy, but I don't think the current rules
> have a problem if followed.
>
> Within the context of this thread, we're dealing with issues that came
> up breaking at 5.XX+1, so after the freeze. Not technically new API,
> but behavioural changes.

Which raises the question of why those behavioural changes were going
in so close to the end.
If behavioural changes were needed by Plasma they should have been in
much earlier - ideally in the 5.XX release.

Do we know why they ended up landing at the very last minute?

>
> David

Cheers,
Ben
[prev in list] [next in list] [prev in thread] [next in thread]