2015-04-30 15:55 GMT-07:00 Friedrich W. H. Kossebau <kosse...@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@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
