The message about Calligra 3.x

Fri May 1 20:09:48 BST 2015

On 1 May 2015 at 05:27, Yue Liu <yue.liu at mail.com> wrote:
> 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

This can work too. Two notes:

1. The question remains about releasing stable version.
It's the same: 2.99 stable would not exist. I think we still need the
BETA sign everywhere.
Others please also how would the unusual message "calligra 2.100
released" would sound.
For now this sounds as something unusual. I know this is just a number, but...

2. We have (and will have) some logic in cmake regarding SOVERSION, etc.
I contibute there and from what I can say it's convenient to assume
major version >= 3.

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

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