<div dir="ltr">I wonder how we can utilise one of the new container distribution formats such as flatpak or snap for distributing betas.  Probably need to do some research, would be handy to not rely on distros for pushing out betas, or have users building from source.<div><br><div class="gmail_quote"><div dir="ltr">On Sun, 4 Sep 2016 at 09:06 Dag <<a href="mailto:danders@get2net.dk" target="_blank">danders@get2net.dk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Can't give you much advice on releases ;)<br>
but +1 for stable releases, so we can avoid the odd regression we've<br>
seen in the past.<br>
KReport / KProperty is used in Plan so would be nice to have any planned<br>
API/ABI changes in before release.<br>
<br>
Cheers, Dag<br>
<br>
Jaroslaw Staniek skrev den 2016-08-31 10:45:<br>
> Hello,<br>
> KDE Akademy[1] is starting so I thought it might be a good point to<br>
> push the Beta release button for Kexi and related frameworks:<br>
><br>
> KDb<br>
> KProperty<br>
> KReport (depends on KProperty)<br>
><br>
> tl;dr:<br>
> - we need source distribution of Kexi and the 3 frameworks to get more<br>
> users and contributors<br>
> - we need to find a way for the frameworks to serve both for Kexi<br>
> needs and general user<br>
> - when: release process takes about two weeks, let's add extra week<br>
> for a bootstrap of this process<br>
><br>
> Details.<br>
><br>
> As some of us are aware there are 4 repositories in the Kexi family.<br>
> We are no longer "outsourcing" the hard release work to general<br>
> calligra, so there's specific work to do. At first it takes some more<br>
> effort I think. I'll be looking at scripts such from releaseme.git or<br>
> kde-dev-scripts.git.<br>
> Advices are welcome here (Boudewijn has offered useful advice already<br>
> based on the experience with Krita releases).<br>
><br>
> Despite extra work, there are advantages of the separate releases,<br>
> more control and possibility of finer-grained releases, not a "release<br>
> all or nothing" scheme. Please note this is about the first level of<br>
> releases - source code and message translation files. Binaries would<br>
> appear thanks to distributors and separate work for Windows.<br>
><br>
> The three frameworks have various level of maturity, based on<br>
> attention; I'd say the most prepared is KDb, then KProperty, then<br>
> KReport. This especially apply to API and ABI guarantees (e.g. see<br>
> [2])<br>
><br>
><br>
> == How to version ==<br>
><br>
> And here's a challenge: at the moment the main consumer of the<br>
> frameworks is Kexi. Later it shouldn't be like that, otherwise we<br>
> could release a bundled source code based on all 4 repositories.<br>
> There's some consumption of KReport and KProperty in the Calligra Plan<br>
> app. that's it. It may be that someone plays or even uses git versions<br>
> of the code but that was not noticed.<br>
><br>
> So since Kexi is the major consumer, current development priorities<br>
> for the frameworks are rather Kexi-specific and sometimes it's hard to<br>
> keep (or justify fighting for) backward compatibility. A recent<br>
> example is an (August) merge of the Kexi's migration API that formed a<br>
> lower-level database access APIs for KDb. It's already in master<br>
> branch. Fortunately such moves become more rare over time.<br>
><br>
> So how to organize development of the frameworks: not blocking<br>
> development of features or fixes important for Kexi and staying<br>
> (binary) backward compatible? I thought of one approach:<br>
><br>
> - Version 3.x of the frameworks becomes binary compatible on first<br>
> stable release<br>
><br>
> - Version 4.x of the frameworks come into life as soon as needed by<br>
> Kexi and incompatible changes happen there, the version would carry<br>
> the "Beta" stamp for a long time to emphasize that there's no<br>
> compatibility guarantee<br>
><br>
> - Kexi 3.0 gets released as depending on 3.x initially and would<br>
> switch to 4.x when a need for incompatible changes in framework<br>
> appears<br>
><br>
> - Co-installability of 3.x and 4.x is assured, 4.x will never be an<br>
> upgrade for 3.x (a bit similar to situation with libPNG 12, 14, 16)<br>
><br>
> This way we have any chance to see users of the frameworks distributed<br>
> and used.<br>
><br>
><br>
> == Q & A ==<br>
> Q: Why not push the frameworks to the KDE Frameworks 5 family?<br>
> A: Maybe one day but now it's too early and the workforce is too<br>
> limited.<br>
><br>
> [1] <a href="https://akademy.kde.org" rel="noreferrer" target="_blank">https://akademy.kde.org</a> (I am just present there in spirit...)<br>
> [2]<br>
> <a href="https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B" rel="noreferrer" target="_blank">https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B</a><br>
</blockquote></div></div></div>