Releases in 3 months

[Àlex Fiestas]

On Monday 08 July 2013 16:38:02 you wrote:
> Le lundi 8 juillet 2013 16:19:02 Àlex Fiestas a écrit :
> > I did pasted the link in #kontact and #akonadi a couple of times before
> > sending this email :p
>
> I never saw it.
> And paste on irc is not speak with guy which works several project.
Sure, that's why I'm sending the email to kde-core-devel so everybody can be
involved in the discussion.

Once again, this is a proposal nothing is set in stone (not by far).
> > The development time is NOT divided and it is NOT limited to 2 months,
> > instead now master will be always open to include features and once every
> > 3
> > months we'll make a release.
>
> So at a specific date you takes code without freeze before ?!
>
> > For example, if you take a look at this pic:
> > http://community.kde.org/images.community/b/b8/Drawing.png
> >
> > For example between 4.12 branching (15/10) and 4.13 branching (15/01/2014)
> > there will be 3 months. If for whatever reason your feature is not stable
> > to go into 4.13, you can delay it for 4.14 which will happen 3 months
> > after, so not much is changing of how we are doing things now.
>
> So you will take code from what ?
> I will continue to work on master so you will take a broken code ?
>
> It’s more logical to freeze master until release otherwise you will release
> broken code it’s sure.
>
> > Said it in another way, if you want to keep a 6 months release schedule
> > you
> > can ! this just allow others to ship features more often.
> >
> > Finally, I'm NOT proposing this because kde-workspace and kdelibs are
> > frozen, that's just an opportunity to change the release cycle since it
> > will affect less people. You can read the motivation here:
> >
> > http://community.kde.org/KDE_Core/ReleasesProposal#Motivation
>
> "The main motivation for this change is to reduce the amount of time between
> releases and make them simpler, making us able to deliver new features
> faster to our users while keeping if not improving the current quality. “
>
> "deliver new features faster” ? :) new feature broken yes (less time more
> bugs)
Not if you only put things in master that have been tested and proven to work.

Using the example you gave about the "akonadi batch notifications", in the new
schedule it would have been merged just after the branching, so we would have
4 months to test it until the release (and the bug was fixed within a month
anyway).