oh, I'm not really keen on giving people this shortcut - it's quite common for function types to change, and that's an incompatible change which needs the library major to be bumped.
if people don't want to look at the full diff they should just bump major anyway (but they should also be aware that library major bumps cause a problem for -stable port updates, so they should really look at the full diff anyway). if you're tracking upstream releases reasonably closely, much of the time it's not too slow to check over a diff anyway (for autoconf-based projects it can save a bit of time to rm any configure scripts and Makefiles before diffing). what do others think? In gmane.os.openbsd.www, Charles Smith wrote: > s/fonctions/functions/ > > > > Index: specialtopics.html >=================================================================== > RCS file: /cvs/www/faq/ports/specialtopics.html,v > retrieving revision 1.3 > diff -u -r1.3 specialtopics.html > --- specialtopics.html 18 Jun 2009 21:40:26 -0000 1.3 > +++ specialtopics.html 24 Jun 2009 07:40:43 -0000 > @@ -86,7 +86,7 @@ > should trigger a major number bump. > <li>A good hint is to compare the output of <b>nm -g > oldlib.so.X.Y | cut -c10- | grep -e^T</b> and <b>nm -g newlib.so.X.Y | cut > --c10- | grep -e^T</b>. This won't show if fonctions arguments type changed, > +-c10- | grep -e^T</b>. This won't show if functions arguments type changed, > but at least you'll see quickly if some functions were added and/or removed. > </ul> > <p> > >
