Well, KDevelop 4.0 was more than 2 years behind KDE 4.0. And like Sven
said, after 4.0 we preferred feature-heavy releases focused on getting new
functionality out as soon as it was ready.
On Fri, Nov 5, 2021 at 5:30 PM Jonathan Riddell wrote:
> On Sat, 30 Oct 2021 at 09:36, Sven Brauch
On Friday 27 June 2008 17:12:08 Sebastian Kügler wrote:
+1, but has anything significant changed in this branch lately?
You can include latest KDevelop 3.5.2 release, for example. It has lots of
bugfixes and several ruby support features
On Sun, Mar 30, 2008 at 3:38 AM, Aaron J. Seigo [EMAIL PROTECTED] wrote:
I agree with what you have said, Alex. I think getting concerned over the use
of the term scripting language is a bit unnecessary, it's just a commonly
used term is all.
Sure :) I just wanted to stress my point that
On Sun, Mar 30, 2008 at 10:49 AM, Andras Mantia [EMAIL PROTECTED] wrote:
Sorry, in the beginning I couldn't find the good word, but in fact I
meant interpreted languages,
Well, actually I never stress the fact Ruby or Python are interpreted.
It doesn't matter. Currently the best
On 7/11/07, Tom Albers [EMAIL PROTECTED] wrote:
No, it's not if you read the whole thread. Problem is that this 'release when
ready' works great in small open source projects. But when there are
hundereds people working on one project, there is no time when everyone is
'ready' at the same
On 7/6/07, Troy Unrau [EMAIL PROTECTED] wrote:
The proposal is to add another layer to the release stack called 'gamma' or
similar. The release cycle up until Oct 23rd would remain unchanged, except
perhaps the RC sections might need to be renamed as gamma candidate, for
instance.
Sorry for
On 5/3/07, Allen Winter [EMAIL PROTECTED] wrote:
I'm talking about the policies dealing with a public API. i.e, dpointers,
inline
methods, apidox, .. stuff like that.
Basically we either adhere to kdelibs policies here or strive to.
I didn't mean coding style. The licensing
must be
On 5/3/07, Allen Winter [EMAIL PROTECTED] wrote:
I'm talking about the policies dealing with a public API. i.e, dpointers,
inline
methods, apidox, .. stuff like that.
Basically we either adhere to kdelibs policies here or strive to.
I didn't mean coding style. The licensing
must be
On Tuesday 06 March 2007 11:35, Sebastian Kügler wrote:
- KDevelop 3.5 needs to be usable to develop KDE4 applications well
KDevelop 3.4 already is. We use it to develop KDevelop4.
___
release-team mailing list
release-team@kde.org
