3.0 Beta releases, compatibility

[Dag]

Can't give you much advice on releases ;)
but +1 for stable releases, so we can avoid the odd regression we've 
seen in the past.
KReport / KProperty is used in Plan so would be nice to have any planned 
API/ABI changes in before release.

Cheers, Dag

Jaroslaw Staniek skrev den 2016-08-31 10:45:
> 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