3.0 Beta releases, compatibility

[Jaroslaw Staniek]

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