[ moving to libtool-patches ] Hi Tor,
* Tor Lillqvist wrote on Tue, May 04, 2010 at 09:00:45AM CEST: > >>> <http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=7890173078d185548f1f058322d8ddc3b18cfc81> > > I am not a native English speaker, but I find the use of "may use" a > bit confusing in the added text. I would suggest changing some > instances of "may use" to "are able to use" and some to "might be > using". (It should be clear in what way I mean, I hope...) Hopefully > that will make the text even clearer. Thanks for the suggestion. I'm not a native speaker either, so I may well be using wrong or suboptimal idioms (sorry for the unintended but unfortunately necessary pun). Back in school, we were taught some rule for distinguishing "may" and "might"; I've long forgotten it and have been going by intuition ever since. However, I love pondering over linguistic issues every once in a while, so please forgive me for expanding a bit. Looked it up in the net now, e.g., <http://grammar.quickanddirtytips.com/may-might.aspx>, tells me that I should be using "might" instead of "may" only for things that are rather improbable to happen. <http://www.fortunecity.com/bally/durrus/153/gramch10.html> tells me that "may" can be used as a more formal form of some meanings of "can" or "is able to", which I think is applicable here. Remains avoidance of repetition, which is generally a good thing in flowing text but not needed so much in technical documentation which is more concerned with correctness. I'll apply the patch below soon unless I hear complaints. Thanks, Ralf Reword alternate versioning algorithm a bit. * doc/libtool.texi (Updating version info): Replace some uses of `may' with `might' or `can' as appropriate. Suggestion by Tor Lillqvist. diff --git a/doc/libtool.texi b/doc/libtool.texi index 987b232..ec24a2f 100644 --- a/doc/libtool.texi +++ b/doc/libtool.texi @@ -2947,7 +2947,7 @@ Instead, use the @option{-release} flag (@pxref{Release numbers}), but be warned that every release of your package will not be binary compatible with any other release. -The following explanation may help to understand the above rules a bit +The following explanation can help to understand the above rules a bit better: consider that there are three possible kinds of reactions from users of your library to changes in a shared library: @@ -2961,14 +2961,14 @@ is needed. In this case, bump @var{revision} only, don't touch @item Programs using the previous version may use the new version as -drop-in replacement, but programs using the new version may use APIs not +drop-in replacement, but programs using the new version can use APIs not present in the previous one. In other words, a program linking against -the new version may fail with ``unresolved symbols'' if linking against +the new version might fail with ``unresolved symbols'' if linking against the old version at runtime: set @var{revision} to 0, bump @var{current} and @var{age}. @item -Programs may need to be changed, recompiled, relinked in order to use +Programs might need to be changed, recompiled, relinked in order to use the new version. Bump @var{current}, set @var{revision} and @var{age} to 0. @end enumerate
