better way to handle required rebuild on library bump

[b. f.]

>I've been using portmaster since I started using freeBSD (about 2 and a half
>years ago) ;)
>My post was a way to deal with things like the recent jpeg update in a more
>efficient manner. Instead of the port committer having to bump the
>portrevision of each port that depeneds on jpeg they could just bump
>MAJORVERSION in jpeg and have the rest of the work done magically

I don't see how this would be better.  (Maybe if you showed us an
implementation it would be clear?)  There has to be a mechanism for
tracking port version numbers in either case.  The current method
relies on this existing mechanism to prompt people to upgrade
dependent ports after a shared library version bump, and this process
is automated, via a script. (The script could be improved, if
necessary, or it could be more closely integrated with commits, so
that it is run automatically.)   The committer has to make some
changes to dependent ports in either case, because the requested
library versions in some LIB_DEPENDS lines will need to be adjusted.
Perhaps if the version requirements in these lines were relaxed or
removed, fewer ports would have to be changed, but that could also be
a source of problems. In any event, at the moment, there is not a
great deal to be gained by avoiding bumping the PORTREVISION numbers,
because these other changes need to be made anyway.  And if I recall
correctly, this has not been the major source of problems for users in
recent large updates, anyway.

You seem to be suggesting a different, parallel mechanism for updates.
 In order to do this, you'd have to augment and change the ports
infrastructure, the base-system package tools, and probably
third-party management tools like portupgrade and portmaster, while
maintaining backward compatibility with older binary packages.  And
you'd have to give people a chance to opt out: they may not _want_ to
rebuild every dependent port, but only some of them.  Under the
current system, they can do as they please.