On 1 May 2015 at 05:27, Yue Liu <yue....@mail.com> wrote: > 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
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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
