4.5 Release Schedule

Sebastian Kügler sebas at kde.org
Mon Apr 12 15:37:45 BST 2010


Thanks Tom for proposing the schedule, it mostly looks good from my point of view.

On Friday 09 April 2010 21:42:24 toma wrote:
> Final problem we had this cycle was changing dependencies until late in the
> schedule. So we added a dependency freeze at the hard feature freeze time.
> People should by then know what they want to add as features for that
> cycle and think about the dependencies they need. During the dependency
> freeze it is not allowed to introduce new dependencies or raise the
> version of existing dependencies.

That's a misconception, as the Virtuoso dependency did not actually change, but a 
new version came out with incompatible data format, both version work, however. A 
dependency freeze won't catch this, it's like if MySQL releases a new version on 
our release day with a new database format -- we can talk to them upfront making 
clear that this hurts continuity, but we have to react to this kind of changes in 
our environment.

On the other hand, this kind of incompatible change is better done before many 
people start using it as in this particular case, there wasn't a released version 
with the incompatible format and distros decided to go with Virtuoso 6 right away.

I agree that it was far from ideal, especially since we (that is Sebastian Trüg 
:-))) had to introduce a database conversion tool out of nowhere, which wasn't 
completely painless.

As to the issue at hand, I've thought about it and I don't think we can do a lot 
about that, other than keeping our eyes open. Suggestions are of course welcome.

Apart from that, a dependency freeze in general makes sense to me.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9




More information about the kde-core-devel mailing list