* Peter Rosin wrote on Tue, May 04, 2010 at 10:05:37AM CEST: > Den 2010-05-03 22:03 skrev Ralf Wildenhues: [...] > >>>>># 3. If the library source code has changed at all since the last > >>>>>update, > >>>>># then increment revision (`c:r:a' becomes `c:r+1:a'). > >>>>># 4. If any interfaces have been added, removed, or changed since the > >>>>>last > >>>>># update, increment current, and set revision to 0. > >>>>># 5. If any interfaces have been added since the last public release, > >>>>>then > >>>>># increment age. > >>>>># 6. If any interfaces have been removed since the last public release, > >>>>># then set age to 0. > >>>> > >>>>Shouldn't step #6 included "changed" as well as "removed"? If you > >>>>change the interface (for example modifying function parameters), > >>>>backwards compatibility is broken too. But only "removed" is listed > >>>>here. > >>> > >>>Well, it is listed in step 4 already. > >> > >>Sure, but if interfaces have been changed, but not removed, the > >>algorithm stops at step #4, > > > >Read the algorithm without any implicit stops in mind, and it will work. > > > >Anyway, your point is good that this is hard to understand, and we've > >addressed that in git master. > > Errrm, is that really so? I tend to agree with Jef here...
I take it that your response is to my "... it will work" sentence, not the paragraph below that. > The algorithm *could* be interpreted such that e.g. the interface change > "int foo(void)" -> "int foo(int)" is an interface addition of int foo(int) > and an interface remove of int foo(void), thus triggering both #5 and #6. > But in that case "changed" need not be mentioned in #4 either. So, because > "changed" is mentioned in #4, it also needs to be explicitly mentioned > in #6. Ah, ok. Yes, you're right. Feel free to commit a patch to s/removed/& or changed/ in 6. Thanks for perservering! Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
