KDE Frameworks Release Cycle

Aleix Pol aleixpol at kde.org
Tue Apr 29 12:50:38 UTC 2014


On Tue, Apr 29, 2014 at 2:33 PM, Harald Sitter <apachelogger at ubuntu.com>wrote:

> ahoy, quick question that just when we discussed this in kubuntu:
>
> On Sun, Apr 27, 2014 at 3:15 PM, David Faure <faure at kde.org> wrote:
> >  * Everything is developed in master, so each release will contain a few
> new
> > features and bugfixes;
>
> > Of course, going with this type of cycle comes with some price of its
> own:
> >  * Features in released modules can only be introduced in a very fine
> grained
> > way so as to not jeopardize the stability;
>
> I suspect that's bad wording, but those two things sound contradicting to
> me.
>
> If everything is developed in master (i.e. features are not developed
> in a feature branch and then merged into master) but features mustn't
> affect the stability, how do you ensure latter if someone develops a
> feature locally (alas, no feature branch on git.kde.org) and then
> pushes at any day (since there is no feature freeze)?
>
> HS
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>

By being stubborn in different ways:
- Ensure merged features are unit tested.
- Don't let things get merged if they make other tests to fail.

The idea is that when it's merged, it should already be stable.

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20140429/ced9a5dd/attachment.html>


More information about the release-team mailing list