On 4 September 2016 at 17:28, Adam Pigg <a...@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 <dand...@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
