Qt and KDE version bumping and next version numbering

[Myriam Schweingruber]

On Sun, Sep 19, 2010 at 16:05, Mark Kretschmann <kretschmann at kde.org> wrote:
> On Sun, Sep 19, 2010 at 3:59 PM, Jeff Mitchell <mitchell at kde.org> wrote:
>> On 09/19/2010 07:43 AM, Mark Kretschmann wrote:
>>> On Sun, Sep 19, 2010 at 10:41 AM, Myriam Schweingruber <myriam at kde.org> wrote:
>>>> Hi all,
>>>>
>>>> since we are starting a new version, there are a few things we should consider:
>>>>
>>>> currently we still depend on KDE 4.3 and Qt 4.4. Since  KDE 4.5.1 is
>>>> already is out and Qt 4.7.0 is imminent, also all distributions
>>>> already ship KDE 4.4 and Qt 4.5 AFAIK., we should be able to bump to
>>>> the next version, that is KDE 4.4 and Qt 4.5.
>>>>
>>>> This would also allow us to integrate this merge request:
>>>>
>>>> http://gitorious.org/amarok/amarok/merge_requests/121: Replaced
>>>> deprecated animations API from Context plasmoids
>>>>
>>>> Also, since we will bring in the GSoC students code now, we should
>>>> consider bumping to Amarok 2.4 as our next target, there will be
>>>> enough new features that would justify such a version change.
>>>>
>>>> What do the others think?
>>>
>>> That would be very welcome by me, especially because we could then
>>> make use of the utterly delightful QWeakPointer class from Qt 4.6.
>>
>> No we couldn't -- Myriam proposed bumping to Qt 4.5, not 4.6.
>
> Ah, Myriam got a bit confused there, I just talked to her. KDE 4.4
> actually depends on Qt 4.6 (not 4.5, which we already depend on).
>
> So all is good, if we start depending on KDE 4.4.
>

Yes sorry, I mistyped that one.

So if nobody opposes that move til the end of the week, I will change
the README and ask markey to bump the version in cmake. I guess the
silence is due to you all silently agreeing :)

BTW, somebody should change the git branch number, it still says
2.3-git and I don't know how to do that.


Regards, Myriam.

-- 
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)