<div>Nota : Andreas, to improve the binary compatibilty, we can use a d private internal class everywhere to contain all private members.</div>
<div> </div>
<div>Like this, if you add a new private member in a class the benary is not broken because private member declarations are include in cpp files not in hpp. </div>
<div> </div>
<div>This way increase the compilation time too... When the API will be more stable for you, i can patch the library like this. I know very well this technic since i have patched all digiKam core implementation. Also, libkexiv2 and libkdcraw are implemented using d private class.
</div>
<div> </div>
<div>Friendly</div>
<div> </div>
<div>Gilles <br><br> </div>
<div><span class="gmail_quote">2007/3/4, Angelo Naselli <<a href="mailto:anaselli@linux.it">anaselli@linux.it</a>>:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Alle 12:32, domenica 4 marzo 2007, Andreas Huggel ha scritto:<br>> On Sunday 04 March 2007 15:14, Gilles Caulier wrote:
<br>> > Angelo, Achim,<br>> ><br>> > The Exiv2 library coordinator is in this room (Andreas).<br>> ><br>> > Andreas, what do you think about versionning number?<br>> ><br>> > Gilles
<br>><br>> Exiv2 and it's interface are still unstable. Thus the 0.x version number<br>> and the use of the simple library versioning mechanism. The API/ABI<br>> change with every version, although sometimes in subtle ways (which is
<br>> worse); the current versioning system makes this very clear. The other<br>> versioning system is only meaningful if API/ABI are reasonably stable.<br>> Exiv2 will get there too.<br>><br>> For an example of a subtle API change see
<br>> <a href="http://uk.groups.yahoo.com/group/exiv2/message/523">http://uk.groups.yahoo.com/group/exiv2/message/523</a><br>I don't fully agree with that, if a bug fixing change the api, or an<br>api changes you can always break binary compatibility using  -version-info
<br>just increasing the first number and let others (two) to zero.<br>The right now versioning system is by default a compatibility breaker.<br>And you can never say from now on i won't break it because you change<br>
the name of the library and who use the old one cannot use the new one<br>without rebuilding itself.<br>You can always break binary compatibility using also  -release X.Y<br>IMO libtools is quite clear.<br><br>Angelo<br><br>
_______________________________________________<br>Digikam-devel mailing list<br><a href="mailto:Digikam-devel@kde.org">Digikam-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/digikam-devel">https://mail.kde.org/mailman/listinfo/digikam-devel
</a><br><br><br></blockquote></div><br>