[Kde-pim] Kolab stable branches

[Mark Gaiser]

On Fri, Apr 11, 2014 at 10:20 PM, laurent Montel <montel at kde.org> wrote:
> On vendredi 11 avril 2014 22:01:11 Mark Gaiser wrote:
>> On Fri, Apr 11, 2014 at 10:42 AM, Christian Mollekopf
>>
>> <mollekopf at kolabsys.com> wrote:
>> > Hey,
>> >
>> > As you know we have with Munich a large project that is going to be using
>> > Kontact as their desktop client (hurray!). In order to stabilize Kontact
>> > I'm going to maintain stable branches of all relevant repositories,
>> > allowing us the move slower (for stability) or faster (because we need new
>> > features) as required.
>> >
>> > These branches are based on 4.13 and are hosted on Kolab Systems
>> > infrastructure. If anyone is interested I can push them to github though
>> > (it's just 4.13 with a bunch of patches from master).
>> >
>> > For the work that needs to be done I plan to generally work on master and
>> > then cherry-pick the result of that work to the stable branches, to
>> > ensure all our work goes upstream.
>> >
>> > For discussions that are related to the stable branches only, and that
>> > don't concern upstream, there's a mailing-list,
>> > kde-team at lists.kolabsys.com, you're welcome to subscribe if you're
>> > interested
>>
>> For clarity: https://lists.kolabsys.com/mailman/listinfo/kde-team
>>
>> something I've been wondering but never asked. Why don't you just
>> declare kontact 4.13 done, feature frozen and put it in bug fix only
>> mode?
>
> Because we will not freeze it as discussed on other mail.
>
>> Then create a new branch for version 5.0 (kontact 5.0) on kde's
>> git infrastructure and work on top of that?
>>
>> It's not like a lot of people are working on kontact anyway. Just
>> looking at the git log (kdepim repository), it's tons of small bug
>> fixes by Montel Laurent and a bit of Sergio Martins commits mixed in
>> between. But it doesn't seem like anything major is going on in there.
>
> Interesting "small bug fixe"...
Small in lines of code.
But i know - sadly out of experience - that it can take days to figure
out a fix for an issue that can end up to be just a simple one liner
once you see the diff :)

Bug fixes are always fine, even when the code is locked down for features.
>
>
>>
>> But what you are planning - feature wise - is going to be quite a
>> change anyway so upping the major version should be justified, right?
>
> Please read other mail it's better
>
> To conclude we will not freeze master we will create a 4.14 kdepim.
>
> Regards
>
>> _______________________________________________
>> KDE PIM mailing list kde-pim at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-pim
>> KDE PIM home page at http://pim.kde.org/
>
> Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53,  http://www.kdab.fr
>
> --
> Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53,  http://www.kdab.fr
>
>
> _______________________________________________
> KDE PIM mailing list kde-pim at kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/