<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 10:06, Dag <span dir="ltr"><<a target="_blank" href="mailto:danders@get2net.dk">danders@get2net.dk</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">Can't give you much advice on releases ;)<br>
but +1 for stable releases, so we can avoid the odd regression we've seen in the past.<br>
KReport / KProperty is used in Plan so would be nice to have any planned API/ABI changes in before release.<br>
<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">OK, Dag. One advice. You can depend on strict version like ​3.0.0 or if you ever need specific behaviour that's since 3.x.y, x>0,y>0, you can update the dependency too. If we perform API/ABI changes that would be >= 4.0.0 version so if you still stay with 3.x.y dependency in Calligra Plan, you are safe (as long as packagers don't treat version 4 as upgrade/replacement for 3 - that's a major thing to check, like with libPNG).<br></div><br><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">Small update. KDb in master already has co-installability enabled. Its lib is called libKDb3.so. Major commit is 6c423feac9ca124 if someone wants to get the idea.<br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">Interesting: users don't need to perform _any_ adjustments after such changes, the cmake's config scripts transparently find proper version, so you still refer to the lib by name, as "KDb". In Kexi master it's now:<br><br>find_package(KDb 2.96.7 REQUIRED COMPONENTS ....)<br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default"><br>I'd imagine the same would be supported for the other 2 frameworks and maybe even Kexi internal libs.<br><br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">Let's hear if there are any remarks from packagers.<br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default"><br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">PS: co-installability means no two files from two incompatible installations are the same so packages can't be in conflict (unless packagers want to set them as such, which we would like to discourage).<br><br><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">
Cheers, Dag<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
Jaroslaw Staniek skrev den 2016-08-31 10:45:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
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 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 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] <a target="_blank" rel="noreferrer" href="https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B">https://community.kde.org/Poli<wbr>cies/Binary_Compatibility_Issu<wbr>es_With_C%2B%2B</a><br>
</blockquote>
</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>