[RFC] KConfig API stuff

Jos Poortvliet jospoortvliet at gmail.com
Mon Oct 22 08:04:07 BST 2007


On 10/22/07, Andreas Hartmetz <ahartmetz at gmail.com> wrote:
> Am Sonntag, 21. Oktober 2007 22:38:31 schrieb Torsten Rahn:
> > On Sunday 21 October 2007 20:51:53 Riccardo Iaconelli wrote:
> > > Personally, I'm all for marking 4.0 still "instable", and have 4.1 as
> > > first binary compatible release for the whole 4 cycle.
> >
> > Erm no. That's no option. What's next?
> > Redefining "men" as "women", "programmers" as "clowns" and "KDE"
> > as "Enlightenment 2" ?
> >
> We are making way, way more progress than Enlightenment AFAICS :)
>
> > If we are not there yet then we are simply not there yet. On the other hand
> > you need to be aware that no release will be perfect.
> >
> > It's no issue if a major release with huge architecture changes gets lots
> > of functional regressions and some additional bugs. But trying to
> > redefine "Betas" as "RCs" and "stable" release numbers as "instable" is the
> > best way to make people take you not serious anymore and spread confusion
> > everywhere.
> >
> > Torsten
> >
> Heh, I forgot about the possibility to do a gamma release. That indeed looks
> like the best course of action to me, better than a 4.1 that is allowed to
> break BC.
> About anything that says "release" in its name is fine with me.

I wonder - the Gnomes don't do major releases because they release a
new sublibrary for certain stuff with a different name and a new API.
Wouldn't that be possible for KDE? I mean, now it's KConfigBlaBla,
rename it now to K3ConfigBlaBla if you anticipate binary changes and
add a K4ConfigBlaBla.

Or would supporting two libs and the memory usage etc be too much, we
want to keep it clean? If this isn't an option, my totally
insignificant vote goes to BIC changes for KDE 4.1...




More information about the kde-core-devel mailing list