KDevelop and Frameworks

[Milian Wolff]

On Friday 04 July 2014 17:29:47 Aleix Pol wrote:
> On Fri, Jul 4, 2014 at 4:36 PM, Kevin Funk <kfunk at kde.org> wrote:
> > On Friday 04 July 2014 12:15:48 Aleix Pol wrote:
> > > On Fri, Jul 4, 2014 at 10:59 AM, Milian Wolff <mail at milianw.de> wrote:
> > > > On Friday 04 July 2014 01:08:13 Aleix Pol wrote:
> > > > > Hi,
> > > > > I just saw Alexander Richardson review request about deprecated
> > > > 
> > > > KSharedPtr
> > > > 
> > > > > and first thing I thought "why didn't I do that already?". Well, the
> > > > > thinking behind was to do a minimalistic port [1] while features
> > > > > were
> > > > > developed in master, so we could merge back easily.
> > 
> > Same intention here. Didn't want to do invasive changes as long as we keep
> > merging back changes from master.
> > 
> > > > > KDevelop 4.7 has been branched now, KF 5.0 has been released, so
> > 
> > it's a
> > 
> > > > > good moment to put it on the table.
> > > > > How do you guys feel about a: git merge frameworks?
> > 
> > +1
> > 
> > > > Fine with me. I'll work on 1.7 until its released anyways and that
> > 
> > should
> > 
> > > > give
> > > > me enough time to setup a kf5 toolchain.
> > > > 
> > > > Speaking of which, we will have to update our wiki HowToCompile page,
> > 
> > and
> > 
> > > > at
> > > > least announce it also on our user lists, the planet and our website.
> > > > There
> > > > are, after all, a lot of people who build kdev* from master.
> > 
> > Furthermore,
> > 
> > > > I
> > > > would appreciate it, if either of those who successfully built
> > > > KDevelop
> > > > frameworks can document that in every detail. Paste your
> > > > kdesrc-buildrc
> > > > and
> > > > dependent included configuration files. Create a list of frameworks
> > 
> > that
> > 
> > > > KDevelop requires.
> > > > 
> > > > Also, I'm not sure how much master and 1.7 diverged. If there happened
> > 
> > a
> > 
> > > > lot,
> > > > I vote for branching off master into a "legacy" branch just for people
> > > > that
> > 
> > Do we really need that? 4.7/1.7 *is* legacy and we should just try
> > stabilizing
> > that one, not yet another branch.
> > 
> > > > stick to KDE 4 for now. Feature development will go to master/kf5 of
> > > > course.
> > > > Finally, I want to know what our GSOC students think of this (CC'ed).
> > > > Would it
> > > > be OK for you to setup a KF5 toolchain and continue your work there?
> > > > If
> > > > not, I
> > > > guess it would be fine if we go the "legacy" way proposed above, and
> > > > you'll
> > > > continue your work there. Once GSOC is over, we can merge/rebase it on
> > > > frameworks.
> > > > 
> > > > Bye
> > > 
> > > That's a good point, maybe it would be interesting to wait until GSoC is
> > > over to release a 4.8 version, so users can take advantage of the
> > 
> > on-going
> > 
> > > GSoC projects.
> > > 
> > > I don't think the GSoC students should change the platform they work on
> > 
> > in
> > 
> > > the middle of the project.
> > > 
> > > Aleix
> > 
> > Personally I'm not to fond of another 4.8. We should just focus on KF5 now
> > for
> > feature development and focus on 4.7/1.7 for stabilizing. I'd consider
> > this
> > the last KDE4 release. Otherwise we'll have to merge back changes which
> > causes
> > additional work-load (And we still could not do invasive changes to the
> > frameworks branch, which is required to get rid off kdelibs4support and
> > friends).
> > 
> > Regarding GSoC: I think it depends on the GSoC project.
> > 
> > For both Denis and me it probably makes sense to base our work directly on
> > KF5. Personally, I think both projects would fit into a shiny KF5 release
> > announcement. So people also have a good reason to adopt the KF5 version
> > of
> > KDevelop early.
> > 
> > Sergey's work is already part of 4.7/1.7, hence he should continue working
> > on
> > these branches.
> > 
> > Makes sense?
> > 
> > Greets
> > 
> > --
> > Kevin Funk
> 
> Well, we shouldn't be adding new features on .7, so if sergey, denis or you
> need to enhance something in kdevplatform or KDevelop you can and keep the
> plugins suitable for kdev4. It could be interesting that people could try
> kdev-clang and kdev-qmljs after this summer on kdevelop 4.

Right, the thing is that 4.7 is string and feature frozen and thus we cannot 
merge the new functionality from Sergey there. So a legacy branch, or say - 
just a sergey-gsoc2014 branch or similar - would be required. I also have no 
intention of doing another KDE4 feature release, only 4.7 bug fix releases.

> But then that's given the premise that you want your work functional in
> kdev4, which is especially interesting for clang and qmljs, although I'm
> unaware of the status of the plugins.

Yep, I think these two can decide on their own what they want to target.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de