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