Re: caught between a rock and a hard place: new libtool versioning

On 18/08/06, Robert Story <rstory@freesnmp.com> wrote:
> So Dave, do you really think we should go this route (eg 540), or were you
> just throwing it out to see what the reaction would be?

Why Robert, I'm shocked to the deepest core of my being that you could
even *begin* to contemplate that I might be capable of such a
duplicitous action.....



I must admit that I'm drawn to Wes' original position - a patches
branch shouldn't include incompatible changes, so ought to continue
with the same library number throughout.
In which case I'd suggest using '54' for the 5.4.x branch.
(Still relatively large, but not ridiculously so - so that's a
semi-serious suggestion, as opposed to last night's offering).

That's the purist position. Pragmatically, that might not be 100%
sustainable. But just allowing one single library change within a
given patches branch feels extremely shortsighted. How would we
decide when to allow that one change? And what we would do when we
wanted to make another (possibly more vital) change in the same line.
Reminds me of the "Rule of One" in Lloyd Biggle's "Still Small
Voice of Trumpets"!


Now I'm no expert on library version management, but is it true that
we're restricted to a single version number? I'm sure that I've seen
shared libraries named something like

libwombat.so.1
libwombat.so.1.3
libwombat.so.1.3.6.1

Isn't that exactly the sort of approach needed for this situation -
later libraries on a given patch branch should be "mostly compatible"
with earlier ones?

But I might well have completely misunderstood how all this works.


Dave

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=...057&dat=121642
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders