3.0 Beta releases, compatibility

Sun Sep 4 17:58:34 BST 2016

On 4 September 2016 at 17:28, Adam Pigg <adam at piggz.co.uk> wrote:

> I wonder how we can utilise one of the new container distribution formats
> such as
> 
> 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.
>

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.
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).

Flatpaks or snaps would let us distribute with more control in hand (if we
have workforce for that!) but I would say distros do their great job.
I don't see problems distros releasing betas/devel versions. As it's the
case with GIMP which has versions stable X*2 and devel X*2+1.
Also where coinstallable versions are expected by users it's widely
supported (Qt, gcc...).

>
> On Sun, 4 Sep 2016 at 09:06 Dag <danders at get2net.dk> wrote:
>
>> 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
>>
>

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20160904/4457121d/attachment.htm>