The message about Calligra 3.x

[Yue Liu]

2015-04-30 15:55 GMT-07:00 Friedrich W. H. Kossebau <kossebau at kde.org>:
>
> 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.

+1 for 2.99, we can bump to 2.100, 2.101, 2.102 ... until it's usable as 2.9.x

>
> 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
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel