Am Dienstag, 6. Mai 2008, um 18:18 Uhr, schrieb Tom Albers: > Op dinsdag 06 mei 2008 17:56 schreef u: > > Am Dienstag, 6. Mai 2008, um 17:17 Uhr, schrieb Andreas Pakulat: > > > On 05.05.08 21:24:52, Andras Mantia wrote: > > > > Actually would be nice to see at least a KDevPlatform release. I know > > > > its hard, but maybe makes sense, just like kdelibs was released > > > > before the actual KDE 4.0.0. > > > > > > Well, we could probably do that, but without any guarantees regarding > > > binary compatibility. Especially not for the interfaces, shell, > > > project, sublime, language and vcs libraries. > > > > I have a similar problem. I know at least one person which would like to > > make use of the Okteta libraries (implementing a specialised > > ByteArrayModel) in a 3rd-party project after the 4.1 release. But I know > > for sure the API will change for 4.2 again, so I do not install any > > headers. Right now I had to tell him "bad luck"... > > > > I did not find an explicit rule for this on techbase.kde.org, just > > remember the general unwritten rule "ensure binary interface > > compatibility in minor releases". > > From the policies section: > http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ > "In the KDE project, we will provide binary compatibility within the > life-span of a major release."
Ah, overread it there, thanks. The name "Binary_Compatibility_Issues" does not sound too much like a place for promises to 3rd-party developers :) > > Could this rule be made mandatory only for kdelibs and kdepimlibs? > > So young and evolving libraries could follow the principle "release often > > and early" and get some more feedback, until they are mature enough to > > keep BIC till a next major release. Those interested to make use of such > > libraries would know of the risks and have a reason for still using them. > > Of course the API documentation should contain proper big warnings. > > I disagree. I think it is a must to be BC between minor releases. For everything? > If you want to be bic && public, go to extragear/libs untill you are > ready... What would this change for 3rd-party developers? For me it would be more work, as I would have development spanned between extragear/libs and kdeutils. And it would add an additional (if only soft) dependency between modules. Friedrich _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
