The message about Calligra 3.x

[Friedrich W. H. Kossebau]

Hi Jaroslaw,

thanks for starting the discussion. And meh, I only wanted to write a short 
reply. No time to make it short again, sorry...

Am Mittwoch, 29. April 2015, 23:36:09 schrieb Jaroslaw Staniek:
> Hi,
> I am proposing this looking more from users' optics than from developers':
> 
> We're at 3.0 Pre-Alpha stage now.
> 
> How about then releasing 3.0 Beta 1, 2, .... and never the 3.0 _stable_.
> This approach would be announced in 3.0 Beta 1 already: "3.0 is a BETA
> series".
> 
> Users read it as "experimental", "preview", whatever. "Beta" seems to
> be the best universally understood indicator.
> Just avoid the "3.0 stable" "but preview" mantra, which does not seem
> to be a very safe bet (hint: Plasma 4.0).

IMHO you raise a good point here. What is the purpose of 3.0? So far we 
defined it as something where Calligra has been "ported to Qt5/KF5". Means, 
building against some version of Qt5 and the KF5 frameworks, including 
kdelibs4support module. Ideally without regressions and loss of features.

And to not get lost during the port itself also do not any new features and do 
not any refactoring*.

Which means to me, the average user is not the target group of this release. 
Because they do not gain anything from it (besides feeling at the cutting 
edge), rather risk regressions (cutting edge means wounds ;) ).
Actually, the target group is more ourselves, the developers, no? "3.0" is 
defining a milestone, where we consider the port itself done, where we take 
that branch as the new master branch and where we open the gates for mass 
feature development on it, switching more and more over from doing that on the 
"stable" branch 2.9. It will also be the end of caring to allow merges from 
2.9 ;)

So perhaps it might be an idea not to call it "3.0". But keep "3.0" as version 
id for the first real feature release based on Qt5/KF5, which we consider a 
real improvement over the last feature release based on kdelibs4, so e.g. 
distros should chose it for their users.

So what about using e.g. "2.99" or something equally strange as version for 
the so far called "3.0" milestone? Would still fit the relative numbering. But 
also signal something is not really at a new stage yet, in case non-
developers/non-community testers are exposed to that.

What we might still need to agree on is when this milestone is reached. 
Because turning to feature developement might also result in API changes in 
the libs (and refactoring), and any app not yet ported will bitrot. So how 
long should we wait for those apps which are planned to be ported, but are not 
yet there? (BTW, right now behind are "Author", "Flow", "Gemini", "Kexi", 
while "Active" and "Braindump" staying drop candidates). Simply go with a time 
deadline?

* Yes, IMHO we made a mistake with allowing the exception for KDb, KProperty 
and KReport, as it runs the risk to delay the port of Plan (at least the 
reporting feature) and Kexi, and in turn the whole of Calligra, if things 
should be kept together. But well, now it happened and so those interested 
have to work hard to catch up.

> What's with 3.1? For now I do not know. Maybe we can have 3.1 stable,
> maybe not. Depends on many factors.
> 
> More active sub-projects would achieve their stable milestones by
> then. Or not if they are active or/and daring.

I guess we should also start planning how to handle the Krita split-off that 
is going to happen (for bad or good), if only because the Calligra git repo 
just got too big. But then also the rest of Calligra does not match the 
development speed of Krita, which e.g. resulted in the fork of komain into a 
part of kritaui already. And surely soon in even more forks, because Krita 
devs do not enjoy also porting all the other Calligra apps (or introduce 
regressions which noone catches). Which is sad, but reality. It could be only 
stopped if more people are active again in the non-krita part of Calligra. 

So far plans have been uttered to do that after "3.0". No idea if plans are 
more concrete?

> Also, possible thing is that some apps wouldn't achieve stability
> milestone in the same time. So for example how 3.1 would be called?
> A common denominator would be my bet, i.e. marking all apps included
> as beta. Thus rather giving users a nice surprise (e.g. they would
> note that Krita is ready) than than disappointing them (by the fact
> that in 3.1 "Stable" some apps aren't so stable or feature-complete
> compared to 2.9).

I would propose apps that are not stable again are tagged as STAGING, and thus 
disabled from release builds :) That way development can go on, but only those 
apps that are ready to be delivered to end users are part of the actual 
release.
So if maintainers of Krita, Karbon and Kexi at the planned time of 3.1 release 
consider the state an improvement over the last official released version, 
they would just remove the STAGING tag. And at the time of 3.2 

> What with further 2.9.x releases during all of this? Depending on
> interest/needs/resources they would exist.
> 
> If so as much of co-installability as possible is nice. It would be
> great if Kexi 2.9 can be used for work and 3.0 can be installed by
> users willing to help testing the betas. However I guess the
> dependencies may not so co-installable (kdelibs/KF5)?

kdelibs4 and KF5 libs can be co-installed, they are properly namespaced 
(modulo mistakes), just think of all kdelibs4-based apps running on a KF5-
based Plasma desktop system :)

Coinstalling complete set of apps from Calligra 2.9 and 3.x though will need 
extra work, not only because of executable name clashes (unless we start to 
namespace the apps, e.g. "kexi5" :)). There could be extra tools so one could 
switch the integration from kexi 3.x to and back kexi 2.9 (e.g. registering as 
mimetype handlers). But that also will need support of config forward/backward 
migration, so nothing simple.

But IMHO normal users should not be confused with that, it might rather end up 
in a user experience nightmare.

To get feedback from community users eager to give feedback by testing, 
perhaps app container systems could be used (said anyone "docker"? or whatever 
will be the latest tool there). And then there are the OSX and Win worlds 
where I have no clue of (and interest in ;) ).

Coinstalling some Calligra 2.9 app (kexi) and some Calligra 3.x app (krita) 
though might be something that should work, if the official stable kexi is 
still at 2.9, but the official stable krita is at 3.x.
So we should make sure the Calligra libs and plugins are coinstallable. That 
should be doable with proper namespacing, like it is doable with kdelibs4 and 
kf5 libs. Let's aim to support that.

Cheers
Friedrich