From kde-release-team Tue May 06 16:18:00 2008 From: Tom Albers Date: Tue, 06 May 2008 16:18:00 +0000 To: kde-release-team Subject: Re: breaking BIC for new addon libs in minor releases (was: Re: Message-Id: <1354164.aazf76XoEZ () kde ! nl> X-MARC-Message: https://marc.info/?l=kde-release-team&m=121009073326312 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart2830931.izjjRxSoFf" --nextPart2830931.izjjRxSoFf Content-Type: text/plain Content-Transfer-Encoding: 7Bit 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." > 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. If you want to be bic && public, go to extragear/libs untill you are ready... Best, Toma --nextPart2830931.izjjRxSoFf Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team --nextPart2830931.izjjRxSoFf--