Ugh, it sounds really disappointing to wait *half a y= ear*!

The whole way looks very over-conservative to me. I imagine= if someone has a feature to ECM which must be adopted by N `kate`s depende= ncies...

Then the feature can be used in N/2 *years*!!! REALLY??!= !

This turtle driven development could kill many good ideas = %(

Seriously, what the reasons not to depend on th= e latest versions of KF libs? As far as I know, framework libs released *be= fore* KDE Plasma Apps. So, having the latest deps looks pretty normal way t= o get the latest features to me. What could be wrong w/ this approach?

On Wed, Aug 7,= 2019 at 12:01 AM Daan De Meyer <daan.j.demeyer@gmail.com> wrote:

Alright, I thought (wrongly) that KDE applicat= ions always depended on
the latest stable KDE Frameworks release. I'll put this on the back
burner for now then.

Regards,

Daan

On Tue, 6 Aug 2019 at 22:39, Dominik Haumann <dhaumann@kde.org> wrote:
>
> Are you talking about kate.git? If so:
> https://github.com/KDE/kate/blob/maste= r/CMakeLists.txt#L8
>
> Kate cannot depend on unreleased KDE Frameworks. I'd even say we s= hould not depend on the latest Frameworks version.
>
> Wait a few months, best at least half a year, then changes like this b= ecome ok.
>
> Greetings
> Dominik
>
> Daan De Meyer <daan.j.demeyer@gmail.com> schrieb am Di., 6. Aug. 2019, = 08:55:
>>
>> Hi,
>>
>> My revision to allow ki18n_wrap_ui to work on targets was merged.<= br> >> Should I wait until the next stable KDE Frameworks release before<= br> >> refactoring Kate's build scripts to use this new functionality= or is
>> it fine to use the new functionality before it is included in a st= able
>> release?
>>
>> Regards,
>>
>> Daan