Planning KDevelop 4.4

[Andreas Pakulat]

Hi,

Am Dienstag, 3. Juli 2012 schrieb Miha Čančula :

> 2012/7/3 Morten Volden <mvolden2 at gmail.com <javascript:_e({}, 'cvml',
> 'mvolden2 at gmail.com');>>
>
>> 2012/7/3 Milian Wolff <mail at milianw.de <javascript:_e({}, 'cvml',
>> 'mail at milianw.de');>>
>>
>>> On Tuesday 03 July 2012 16:30:27 Aleix Pol wrote:
>>> > Hi,
>>> > As already discussed, I'd like to start the process of stabilization of
>>> > KDevelop 4.4 and KDevPlatform 1.4 in order to have a release by end of
>>> > summer. There are two main reasons for that:
>>> > - We can't really release a further kdevelop 4.3.2 due to some problems
>>> > with the git management
>>> > - We have different stable features that can be put in hands of the
>>> users,
>>> > so some fixes. If there's a huge interest, this can be done, though.
>>> >
>>> > The proposed schedule is:
>>> > - feature freeze, 4.4 branch creation: 10th july
>>> > - message freeze: 20th july
>>> > - beta: 1st august
>>> > - rc: 13th august
>>> > - final: 20rd august
>>>
>>> +1 from me as well
>>>
>>>
>> I would really, really love to get:
>>
>> http://git.reviewboard.kde.org/r/104814/
>>
>> and
>> http://git.reviewboard.kde.org/r/105321/
>>
>> Into the 4.4.release.
>>
>> Is that at all possible? Is there anything I can do to make this happen, or should I just forget about that?
>>
>> I would also like to include the testing framework (branch unittest). I
> know Millian is busy, and it's a rather big change, but I'd like to know if
> it's already too late or not.
>

Personally I'd say its too late for that one. Big changes with lots of new
code should be merged shortly after a release was branched off so they get
maximum testing time in master. Once the decision to do a kdevelop4.4 has
been finalized, there is no reason to immediately branch that off to get it
tested and bugfixed for the .0 release and open up master for feature
merges again.

I've been doing this for the last 2-3 years at work and I'd like to believe
that the features developed this way caused oly minimal disruption for the
users. Of course it also means having the discipline to always use the
release branch code for daily work instead of master, but I think with git
the switch is usually easy enough to make that bareable.

Andreas

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120703/0f5394d5/attachment.html>