Hello, KDE Akademy[1] is starting so I thought it might be a good point to push the Beta release button for Kexi and related frameworks:
KDb KProperty KReport (depends on KProperty) tl;dr: - we need source distribution of Kexi and the 3 frameworks to get more users and contributors - we need to find a way for the frameworks to serve both for Kexi needs and general user - when: release process takes about two weeks, let's add extra week for a bootstrap of this process Details. As some of us are aware there are 4 repositories in the Kexi family. We are no longer "outsourcing" the hard release work to general calligra, so there's specific work to do. At first it takes some more effort I think. I'll be looking at scripts such from releaseme.git or kde-dev-scripts.git. Advices are welcome here (Boudewijn has offered useful advice already based on the experience with Krita releases). Despite extra work, there are advantages of the separate releases, more control and possibility of finer-grained releases, not a "release all or nothing" scheme. Please note this is about the first level of releases - source code and message translation files. Binaries would appear thanks to distributors and separate work for Windows. The three frameworks have various level of maturity, based on attention; I'd say the most prepared is KDb, then KProperty, then KReport. This especially apply to API and ABI guarantees (e.g. see [2]) == How to version == And here's a challenge: at the moment the main consumer of the frameworks is Kexi. Later it shouldn't be like that, otherwise we could release a bundled source code based on all 4 repositories. There's some consumption of KReport and KProperty in the Calligra Plan app. that's it. It may be that someone plays or even uses git versions of the code but that was not noticed. So since Kexi is the major consumer, current development priorities for the frameworks are rather Kexi-specific and sometimes it's hard to keep (or justify fighting for) backward compatibility. A recent example is an (August) merge of the Kexi's migration API that formed a lower-level database access APIs for KDb. It's already in master branch. Fortunately such moves become more rare over time. So how to organize development of the frameworks: not blocking development of features or fixes important for Kexi and staying (binary) backward compatible? I thought of one approach: - Version 3.x of the frameworks becomes binary compatible on first stable release - Version 4.x of the frameworks come into life as soon as needed by Kexi and incompatible changes happen there, the version would carry the "Beta" stamp for a long time to emphasize that there's no compatibility guarantee - Kexi 3.0 gets released as depending on 3.x initially and would switch to 4.x when a need for incompatible changes in framework appears - Co-installability of 3.x and 4.x is assured, 4.x will never be an upgrade for 3.x (a bit similar to situation with libPNG 12, 14, 16) This way we have any chance to see users of the frameworks distributed and used. == Q & A == Q: Why not push the frameworks to the KDE Frameworks 5 family? A: Maybe one day but now it's too early and the workforce is too limited. [1] https://akademy.kde.org (I am just present there in spirit...) [2] https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek