Re: libtool versioning
* Ralf Wildenhues wrote on Tue, May 04, 2010 at 07:56:12PM CEST: I'll apply the patch below soon unless I hear complaints. Based on the very mixed feedback for this patch, let's drop it. Thanks everyone for feedback tho, 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.
Re: libtool versioning
Den 2010-05-04 20:00 skrev Ralf Wildenhues:
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.
Ah, indeed.
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.
I've pushed the attached patch...
Cheers,
Peter
2010-05-05 Peter Rosin p...@lysator.liu.se
Clarify versioning algorithm documentation.
* doc/libtool.texi (Updating version info): Be explicit
about setting age to zero on interface change.
Reported by Jef Driesen jefdrie...@hotmail.com
--
They are in the crowd with the answer before the question.
Why do you dislike Jeopardy?
diff --git a/doc/libtool.texi b/doc/libtool.texi
index f73f5a7..bbc22f4 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -2927,8 +2927,8 @@ If any interfaces have been added since the last public
release, then
increment @var{age}.
@item
-If any interfaces have been removed since the last public release, then
-set @var{age} to 0.
+If any interfaces have been removed or changed since the last public
+release, then set @var{age} to 0.
@end enumerate
@stro...@emph{never}} try to set the interface numbers so that they
Re: libtool versioning
I am a native English speaker, so here are my 0.02: On 2010-05-04 12:56, Ralf Wildenhues wrote: -The following explanation may help to understand the above rules a bit +The following explanation can help to understand the above rules a bit Leave this as may. -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 Again, may. -the new version may fail with ``unresolved symbols'' if linking against +the new version might fail with ``unresolved symbols'' if linking against OK. -Programs may need to be changed, recompiled, relinked in order to use +Programs might need to be changed, recompiled, relinked in order to use I think this is OK as well. Yaakov Cygwin/X
Re: libtool versioning
On Tue, 4 May 2010, Ralf Wildenhues wrote:
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.
As a native english speaker, I don't think that these particular
improvements are improvements. I like the existing text better.
Bob
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
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libtool versioning
On 04/05/2010 18:56, Ralf Wildenhues wrote:
I'll apply the patch below soon unless I hear complaints.
Complain is too strong a word for what I'm about to do... nitpick, quibble
or kibbitz might be better :) Disclaimer aside, ...
-The following explanation may help to understand the above rules a bit
+The following explanation can help to understand the above rules a bit
Either might or may sound appropriate here, but can is a bit
odd-sounding to this native speaker's ears.
If we were re-wording the sentence to make the listener the explicit
subject, we would write You may find the following explanation helpful or
You might find the following explanation helpful but not You can find the
following explanation helpful; the first two describe something that is a
possible state of affairs, but in the can formulation it sounds like the
speaker is giving the listener permission to find the explanation helpful.
Saying that the explanation can help makes the explanation sound like an
active agent rather than a passive object: it is the reader who can or can not
help themselves, using the explanation to do so, rather than the explanation
that jumps up and sets about helping the reader.
-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
I'd have left this one alone, the use of may emphasises that it is
conditional/subjunctive, which I think is the more important sense of the
sentence than the are able to sense which is implied.
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}
These last two I'd say too close to call, purely a matter of personal taste.
cheers,
DaveK
