Re: libtool versioning

[Ralf Wildenhues]

[ 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