Skip to Content.
Sympa Menu

freetds - RE: shared object version numbers

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'TDS Development Group'" <freetds AT franklin.metalab.unc.edu>
  • Subject: RE: shared object version numbers
  • Date: Tue, 24 Sep 2002 11:33:52 -0400


> From: Castellano, Nicholas [mailto:Nicholas_Castellano AT acml.com]
> Sent: September 24, 2002 9:42 AM
>
> I removed an interface (tds_reset_msg_info()) from libtds
> yesterday. I was
> going to bump the libtds major version number, but I decided
> to actually go
> read the libtool docs first. They strongly suggest bumping
> up the library
> version information only immediately before a release. So,
> I'm going to
> leave it alone. Jim, perhaps bumping up the version numbers
> appropriately should be added to doc/README.releasing?

Nick, I'm glad you brought this up. It seems to me it's less error-prone to
bump the version number now, once. That way we avoid last-minute revamping
of the makefiles. If you add a comment such as:

## 0.60.1 was c:r:a
## Tue Sep 24 10:46:42 EDT 2002 nsc bumped (R)elease.

that's enough information to revisit the ChangeLog or whatever if we wanted
to know what you had in mind, and easy enough that it's not a burden (I
hope).

That way, anyone making further changes to the code can see 1) what was the
last released version, and 2) what does the present number mean, by
definition? By applying libtool's rules at each juncture, each of us can
see "in real time" where the version number is heading. By making a note of
the prior release's number, we can heed libtool's warning about
overincrementing.

As regards README.releasing, yes.

I realize that my suggestion imposes some version management work on people
who rely on nightly snapshots or CVS, who may not be expecting the version
to change. Those folks have to subscribe to the list if they want to
succeed, and we can easily help them straighten out anything goofy. In
fact, they're better off, because they won't be swapping in something with a
missing interface, say, and get surprised by its absence at link time.

To avoid ambiguity, I propose to increment R (and only R) as part of
releasing, so that the version number would clearly differentiate releases
from snapshots. Better one small extra increment than one too few, I would
say.

At the risk of flogging a dead horse, one last comment. I read the libtool
doc as advice on version numbering vis-a-vis releases, not as project
management advice. From a public perspective, we're following their
recommendation.

> On a related note, the libtool documentation always mentions
> version info
> specifications with colons (like -version-info 0:0:0), while all our
> Makefile.am's us spaces (like -version-info 0 0 0). Why do
> we use spaces?

Thanks for pointing that out. I followed Steve's lead, and I'm still
learning. Go ahead and correct it at your convenience, if you don't mind,
else I will.

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.






Archive powered by MHonArc 2.6.24.

Top of Page