Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
On Friday 09 May 2008, David Faure wrote: > On Tuesday 06 May 2008, Tom Albers wrote: > > Op dinsdag 06 mei 2008 18:46 schreef u: > > > Am Dienstag, 6. Mai 2008, um 18:39 Uhr, schrieb Tom Albers: > > > > Op dinsdag 06 mei 2008 18:30 schreef u: > > > > > > I disagree. I think it is a must to be BC between minor releases. > > Not for a rarely-used lib like one that kdeutils would provide, IMHO. Wearing my distro packagers hat, not being binary compatible is acceptable *IF* you remember to also bump the SONAME /Sune -- How might I explore the software from AutoCAD 2.9 and from the control panel inside Office? You should never mount the URL and you either have to reset a server of a PCI system, or can never ping the GUI on a computer over a driver to the DirectGL pointer, in such way from Explorer 8000 you neither must turn on the laser login, nor need to insert the graphic attachment for telnetting from a AGP mousepad. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
On Tuesday 06 May 2008, Tom Albers wrote: > Op dinsdag 06 mei 2008 18:46 schreef u: > > Am Dienstag, 6. Mai 2008, um 18:39 Uhr, schrieb Tom Albers: > > > Op dinsdag 06 mei 2008 18:30 schreef u: > > > > > I disagree. I think it is a must to be BC between minor releases. Not for a rarely-used lib like one that kdeutils would provide, IMHO. > > > > 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. > > > > > > No, as long as you make releases from the library, it's is just another > > > 'external' dependency. As long as it is not a cyclic dependency as we now > > > face with libkipi, it is not a problem. > > > > We misunderstand each other? > > kdeutils/okteta would depend on extragear/libs/okteta. Now it does not. > > Think of the packagers. And checkouts of KDE's repository. > > No. it is perfectly fine for a kdeutils app to depend on a library. If that > happens to live in kde's svn too, that's fine. > It is up to you to keep the kdeutils app compilable to your latest release of > the lib. I disagree. There's stuff in extragear that needs the "base kde modules" (trunk/KDE/*), so we shouldn't have the reverse dependency. trunk/KDE can depend on kdesupport libs, but not on extragear libs - extragear is compiled *after* trunk/KDE, otherwise we have a cyclic dependency. -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
A Dimarts 06 Maig 2008, Tom Albers va escriure: > Op dinsdag 06 mei 2008 18:30 schreef u: > > > I disagree. I think it is a must to be BC between minor releases. > > > > For everything? > > Yes. I disagree, this was never a promise we made outside kdelibs + kdepimlibs + maybe kdebase-runtime. I agree it is good not changing SC/BC for the sake of doing it but let's not make things imposible to work, or do you want libokteta (e.g) to virtually be forked until KDE5 if current api is not good enough? Albert > > > > If you want to be bic && public, go to extragear/libs untill you are > > > ready... > > > > What would this change for 3rd-party developers? > > You can make a release whenever you like and bump the major so version of > the lib as you like in each release. > > > 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. > > No, as long as you make releases from the library, it's is just another > 'external' dependency. As long as it is not a cyclic dependency as we now > face with libkipi, it is not a problem. > > Toma ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
On 06.05.08 19:01:15, Tom Albers wrote: > Op dinsdag 06 mei 2008 18:46 schreef u: > > Am Dienstag, 6. Mai 2008, um 18:39 Uhr, schrieb Tom Albers: > > > Op dinsdag 06 mei 2008 18:30 schreef u: > > > > > 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... > > > > > > > > What would this change for 3rd-party developers? > > > > > > You can make a release whenever you like and bump the major so version of > > > the lib as you like in each release. > > > > That would be me, but I asked for 3rd-party developers. > > Then, I know I would not make releases independent of the KDE ones, because > > I > > would develop the libs and the program together. So nothing would change > > for > > 3rd parties, just another location. > > The difference is that you have a proper versioning with library version > numbers. 3rd party devels can check for that and adapt their code to those > versions. What has library versioning to do with keeping BC? If a lib breaks BC it increases its so version and can also adjust its major version number. The library doesn't have to follow the global KDE version number at all, for example the kdevplatform libs don't do it for the plain reason that its not very honest to say they are version 4.x. That version would indicate a matureness the library simply doesn't have. > I like to keep minor release from KDE BC and more importantly 3rd party > devels should be able to rely on that. Right, people using a lib need to rely on that lib keeping BC within a major version, that doesn't mean a library can't change BC between releases, it just means it needs to increase its major version. And if the library devs want to release it with KDE and have it as KDE module thats fine too - IMHO. Andreas -- You are a fluke of the universe; you have no right to be here. signature.asc Description: Digital signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
On 06.05.08 18:22:09, Friedrich W. H. Kossebau wrote: > Am Dienstag, 6. Mai 2008, um 18:15 Uhr, schrieb Andreas Pakulat: > > On 06.05.08 17:56:11, Friedrich W. H. Kossebau wrote: > > > 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". > > > > Thats currently only a rule for kdelibs+kdepimlibs - AFAIK. Other > > modules in KDE/ need to decide on that themselves, for example kdegames > > broke BC in their libkdegames library between 4.0 and 4.1. > > Was libkdegames public for 3rd-party development, i.e. have the headers been > installed? AFAIK some apps in extragear and playground use it, AFAIK. > > The techbase > > page explicitly says that the guidelines are not mandatory. > > Which page is that? http://techbase.kde.org/index.php?title=Policies/Library_Code_Policy Right at the top. Andreas -- "Life, loathe it or ignore it, you can't like it." -- Marvin, "Hitchhiker's Guide to the Galaxy" signature.asc Description: Digital signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
Op dinsdag 06 mei 2008 18:46 schreef u: > Am Dienstag, 6. Mai 2008, um 18:39 Uhr, schrieb Tom Albers: > > Op dinsdag 06 mei 2008 18:30 schreef u: > > > > 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... > > > > > > What would this change for 3rd-party developers? > > > > You can make a release whenever you like and bump the major so version of > > the lib as you like in each release. > > That would be me, but I asked for 3rd-party developers. > Then, I know I would not make releases independent of the KDE ones, because I > would develop the libs and the program together. So nothing would change for > 3rd parties, just another location. The difference is that you have a proper versioning with library version numbers. 3rd party devels can check for that and adapt their code to those versions. I like to keep minor release from KDE BC and more importantly 3rd party devels should be able to rely on that. > > > > 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. > > > > No, as long as you make releases from the library, it's is just another > > 'external' dependency. As long as it is not a cyclic dependency as we now > > face with libkipi, it is not a problem. > > We misunderstand each other? > kdeutils/okteta would depend on extragear/libs/okteta. Now it does not. > Think of the packagers. And checkouts of KDE's repository. No. it is perfectly fine for a kdeutils app to depend on a library. If that happens to live in kde's svn too, that's fine. It is up to you to keep the kdeutils app compilable to your latest release of the lib. Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
Am Dienstag, 6. Mai 2008, um 18:39 Uhr, schrieb Tom Albers: > Op dinsdag 06 mei 2008 18:30 schreef u: > > > 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... > > > > What would this change for 3rd-party developers? > > You can make a release whenever you like and bump the major so version of > the lib as you like in each release. That would be me, but I asked for 3rd-party developers. Then, I know I would not make releases independent of the KDE ones, because I would develop the libs and the program together. So nothing would change for 3rd parties, just another location. > > 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. > > No, as long as you make releases from the library, it's is just another > 'external' dependency. As long as it is not a cyclic dependency as we now > face with libkipi, it is not a problem. We misunderstand each other? kdeutils/okteta would depend on extragear/libs/okteta. Now it does not. Think of the packagers. And checkouts of KDE's repository. Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
Op dinsdag 06 mei 2008 18:30 schreef u: > > I disagree. I think it is a must to be BC between minor releases. > > For everything? Yes. > > If you want to be bic && public, go to extragear/libs untill you are > > ready... > > What would this change for 3rd-party developers? You can make a release whenever you like and bump the major so version of the lib as you like in each release. > 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. No, as long as you make releases from the library, it's is just another 'external' dependency. As long as it is not a cyclic dependency as we now face with libkipi, it is not a problem. Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
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 release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
Am Dienstag, 6. Mai 2008, um 18:15 Uhr, schrieb Andreas Pakulat: > On 06.05.08 17:56:11, Friedrich W. H. Kossebau wrote: > > 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". > > Thats currently only a rule for kdelibs+kdepimlibs - AFAIK. Other > modules in KDE/ need to decide on that themselves, for example kdegames > broke BC in their libkdegames library between 4.0 and 4.1. Was libkdegames public for 3rd-party development, i.e. have the headers been installed? > The techbase > page explicitly says that the guidelines are not mandatory. Which page is that? Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
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___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
On 06.05.08 17:56:11, Friedrich W. H. Kossebau wrote: > 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". Thats currently only a rule for kdelibs+kdepimlibs - AFAIK. Other modules in KDE/ need to decide on that themselves, for example kdegames broke BC in their libkdegames library between 4.0 and 4.1. The techbase page explicitly says that the guidelines are not mandatory. Andreas -- Tomorrow, you can be anywhere. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
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". 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. Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
