<div dir="ltr"><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 September 2016 at 17:28, Adam Pigg <span dir="ltr"><<a target="_blank" href="mailto:adam@piggz.co.uk">adam@piggz.co.uk</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr">I wonder how we can utilise one of the new container distribution formats such as <div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​​</div>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></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">​Taking KDb as example here. KDb is and will be so actively following needs of Kexi that IMHO it can't be realistically following a "cathedral" approach to library development in the same time.​ <br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">So I imagine stable KDb is 3 and _stable_ Kexi quickly switched to using KDb 4 beta. "beta" here would rather mean "devel, not for 3rd-party developers", not "unsable". That means any distribution channel that want to offer fresh stable Kexi >=3 would have to also package fresh "devel" KDb releases (probably in addition to "API/ABI stable" KDb releases).<br></div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Flatpaks or snap​s would let us distribute with more control in hand (if we have workforce for that!) but I would say distros do their great job.<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">​I don't see problems distros releasing beta​s/devel versions. As it's the case with GIMP which has versions stable X*2 and devel X*2+1.<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">Also where coinstallable versions are expected by users it's widely supported (Qt, gcc...).<br></div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr"><div><div class="gmail-h5"><div><br><div class="gmail_quote"><div dir="ltr">On Sun, 4 Sep 2016 at 09:06 Dag <<a target="_blank" href="mailto:danders@get2net.dk">danders@get2net.dk</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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 target="_blank" rel="noreferrer" href="https://akademy.kde.org">https://akademy.kde.org</a> (I am just present there in spirit...)<br>
> [2]<br>
> <a target="_blank" rel="noreferrer" href="https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B">https://community.kde.org/<wbr>Policies/Binary_Compatibility_<wbr>Issues_With_C%2B%2B</a><br>
</blockquote></div></div></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a target="_blank" href="http://kde.org">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a target="_blank" href="http://calligra.org">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a target="_blank" href="http://calligra.org/kexi">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a target="_blank" href="http://www.linkedin.com/in/jstaniek">http://www.linkedin.com/in/jstaniek</a></div>
</div></div>