KDevelop and Frameworks

[Aleix Pol]

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.

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.

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20140704/ae573d82/attachment.html>