Releases in 3 months

[Sven Brauch]

I think Nuno's point is very interesting and worth thinking about. To
stick with the firefox example, since they started releasing every
ortography fix in the settings dialog as a new major version, I think
attention in the media to their releases has declined a lot -- nobody
cares any more that a new version of firefox was released since it
happens every three days.

Of course this is not the only and not the most important criterion,
but I still think an eye should be kept on it.

Greetings,
Sven

2013/7/8 Ingo Klöcker <kloecker at kde.org>:
> On Monday 08 July 2013 22:14:28 Aurélien Gâteau wrote:
>> On Monday 08 July 2013 16:26:00 laurent Montel wrote:
>> > Le lundi 8 juillet 2013 16:11:05 Frank Reininghaus a écrit :
>> > > Hi,
>> > >
>> > > 2013/7/8 Àlex Fiestas:
>> > > > Now that kde-workspace and kdelibs are going to be frozen (which
>> > > > in
>> > > > theory
>> > > > means less work for everybody) I'd like to propose a new release
>> > > > schedule
>> > > > to be applied starting with 4.12.
>> > > >
>> > > > Basically the idea is to cut testing time and compensate it by
>> > > > keeping master always in a "releaseable" state, now that two
>> > > > major components are
>> > > > frozen it looks like it is a good time to get used to it.
>> > > >
>> > > > You can read all the proposal in:
>> > > > http://community.kde.org/KDE_Core/ReleasesProposal
>> > > >
>> > > > Before sending this email I have checked with distro people,
>> > > > i18n
>> > > > people,
>> > > > other developers and almost all of them seemed to either like or
>> > > > be
>> > > > neutral
>> > > > about it (only one exception :p) so I hope that the proposal is
>> > > > not a
>> > > > complete disaster.
>> > > >
>> > > > As its name indicates, it is a proposal, so please be
>> > > > constructive in
>> > > > the
>> > > > feedback, we can change as many things as we need.
>> > >
>> > > I like the idea (from the Dolphin development point of view). Most
>> > > of
>> > > the changes that went into master during the past months had
>> > > already
>> > > been tested rather well before they were merged, and the remaining
>> > > regressions were found rather quickly by people who use the master
>> > > branch a lot. Therefore, it would have been nice if some of the
>> > > improvements could have been shipped to users sooner - quite a few
>> > > bugs that had been fixed in master (with patches that were IMHO
>> > > too
>> > > intrusive for the 4.10 branch) months ago were reported again and
>> > > again.
>> > >
>> > > @Laurent:you say that you have "a lot of features to implement",
>> > > and
>> > > that this would not be possible with a shorter release schedule.
>> > > But
>> > > wouldn't it be possible to implement some of the features for the
>> > > next version and the rest for the one after that?
>> > >
>> > > If you think that you
>> > > need more time to stabilize a feature in the master branch, then
>> > > maybe developing the feature in a separate branch and merge it
>> > > once it's finished might be a good idea?
>> >
>> > No it’s not a good idea because nobody tests branch you can see pb
>> > that we had when we merge akonadi branch (last big changes).
>>
>> It is true that we have a problem with getting people to test
>> branches. But this problem is independant from the release schedule:
>> I believe developing in branches is a good way to work, no matter if
>> releases are created every 3 or 6 months.
>>
>> Having said so, I think Akonadi is a bad example because:
>> - It was a huge change, quite the equivalent of a rewrite
>> - It was affecting personal data
>
> Akonadi was developed in a branch. Okay, this branch was called master
> and the stable branch was called KDE 4.4 (IIRC), and, of course, this
> wasn't nice for people who built everything from master. But we tried to
> communicate very clearly that master was not to be used for anything
> expect for KDE PIM development.
>
> And, of course, we did consider using a proper branch, but then we would
> have had to maintain 3 branches: KDE 4.4, Akonadi, and master. Given
> that we didn't and still don't have enough people to even maintain the
> Akonadi branch (aka master) I still think that this decision was the
> only sensible one. The only feasible alternative would have been the
> deletion of master until the first Akonadi-based alpha release.
>
> But all of this is stuff from the past. When we do Akonadi 2 ;-) we'll
> probably choose a different path.
>
>
> Regards,
> Ingo