Re: [Stlport-devel] Versioninig policy
Brought to you by:
complement
From: <fra...@fr...> - 2007-01-25 21:10:31
|
Just for your info I have already did several checks to compare=20 generated binary between 5.1.0 and head revision in 5.1 branch. AFAI can=20 tell we are still compatible for the moment so we have no reason to=20 change our version policy for the moment. I will document this policy in=20 FAQ. Bests Ulrich Eckhardt wrote: > On Tuesday 23 January 2007 22:14, Petr Ovtchenkov wrote: > =20 >> On Tuesday 23 January 2007 16:07, Ulrich Eckhardt wrote: >> =20 >>> Petr, we have a communication problem with the term 'require rebuild'= . >>> =20 >> Ok, let's consider sample. >> >> ------------- header.h: >> template <class T> >> class A >> { >> public: >> A() >> { } >> >> int f(); >> >> private: >> T b; >> }; >> >> template <class T> >> int A<T>::f() >> { /* do something 1 */; return 0; } >> >> int f(); /* in mod_lib1.cc */ >> >> ------------- mod_lib1.cc: >> #include "header.h" >> >> template <> >> class A<char> >> { >> public: >> A() >> { } >> >> int f(); >> >> }; >> >> int A<char>::f() >> { /* do something 2 */; return 0; } >> >> int f() >> { >> A<char> a; >> a.f(); >> >> return 0; >> } >> >> ------------- mod_lib2.cc: >> #include "header.h" >> >> int g() >> { >> A<int> a; >> >> a.f(); >> >> return 0; >> } >> >> ------------- mod_app.cc: >> #include "header.h" >> >> int g(); /* from mod_lib2 */ >> >> int main() >> { >> A<int> a; >> >> a.f(); >> >> f(); >> >> g(); >> >> return 0; >> } >> --------------- >> >> >> mod_lib1.cc -> lib1.so.1.1 (lib1.so.1.1.1) >> =20 > > This lib uses > - mod_lib1.cc > - header.h > and it exports > - int f(); > - the specialisation A<char> (which isn't declared in the header (bad,= =20 > because it can't be used outside this module)) > > =20 >> mod_lib2.cc -> lib2.so.1.1 (lib2.so.1.1.1) >> =20 > > This lib uses > - mod_lib2.cc > - header.h > and it exports > - int g() > > =20 >> mod_app.cc + lib1.so.1.1 + lib2.so.1.1 -> app >> =20 > > This app uses > - lib1 > - lib2 > - mod_app.cc > > =20 >> What about recompilation of app, lib1, lib2, if I made changes >> >> i) in place /* do something 1 */ >> =20 > > This code is inline, so in order to make it take effect you have to rec= ompile=20 > places where it is used. mod_lib2.cc and mod_app.cc use it, mod_lib1.cc= =20 > doesn't, it only uses a specialisation. You don't have to recompile any= thing=20 > though, because none of the exports changed. > > =20 >> ii) in place /* do something 2 */ >> =20 > > This only changes the specialisation. Assuming it was properly declared= in the=20 > header and thus usable from outside, you would only need to rebuild lib= 1.so=20 > to make the change take effect in all programs. > > =20 >> I expect: >> >> i) you must recompile both lib2 and app: if you recompile only one >> you may see something wonderful [instantiation scheme may be very >> different for different compilers and even different options]. >> =20 > > Yes, you might have code that uses the old version and code that uses t= he new=20 > version in one process. This isn't necessarily bad, assuming that the o= bject=20 > itself didn't change (like having different member variables or differe= nt=20 > uses for them). Typically, either the function did something wrong (in = that=20 > case the application is buggy anyway) or you only changed the way it di= d=20 > things (algorithmic changes) that only affect the performance or memory= =20 > usage. I don't expect this to break anything though. > > =20 >> ii) you must recompile only lib1 >> =20 > > Agreed. > > =20 >> So, what about version of lib1? In what case [(i) or (ii)] I should bu= mp >> patchlevel? In what case I should bump minor version? >> >> My opinion --- bump patchlevel as in (i) as in (ii), if (i) imply fix,= not >> new functionality. >> =20 > > Only bump patchlevel in both. All changes are either inline (i) or hidd= en=20 > behind the interface (ii). > > =20 >>> So, just to get you right, you would happily break existing applicati= ons >>> by reusing the same library name for different libraries? So what do = you >>> want to achieve with a) the naming of the generated libraries and b) = the >>> changes in version number? Maybe we should get this question cleared >>> first. >>> >>> Also, we need to differentiate between naming a library and version >>> numbering. Currently, the major and minor version affect the library >>> name. I basically don't care when we increment the version number, on= ly >>> indirectly via the library name. If we separated those, I would not c= are >>> about the version at all and could live with any scheme. >>> =20 >> Reasonable. Shift to 3 numbers names? >> =20 > > That would mean that you could not manage case (ii) (assuming it is a b= ugfix)=20 > by recompiling lib1.so) and exchanging it, because it has a different n= ame. I=20 > would like to avoid that, because it really is binary compatible. > > Uli > > ***********************************************************************= *************** > Visit our website at <http://www.satorlaser.de/> > ***********************************************************************= *************** > Diese E-Mail einschlie=DFlich s=E4mtlicher Anh=E4nge ist nur f=FCr den = Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte = benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichti= gte Empf=E4nger sein sollten. Die E-Mail ist in diesem Fall zu l=F6schen = und darf weder gelesen, weitergeleitet, ver=F6ffentlicht oder anderweitig= benutzt werden. > E-Mails k=F6nnen durch Dritte gelesen werden und Viren sowie nichtautor= isierte =C4nderungen enthalten. Sator Laser GmbH ist f=FCr diese Folgen n= icht verantwortlich. > > ***********************************************************************= *************** > > > -----------------------------------------------------------------------= -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share= your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Stlport-devel mailing list > Stl...@li... > https://lists.sourceforge.net/lists/listinfo/stlport-devel > > > =20 |