Bruce Momjian writes:
> We bump at the beginning only because we _know_ we want new users to use
> the newer library. (Does the runtime linker know to get the highest
> minor numbered library with the same major number?)
No, the run-time linker only looks at the major version.
> Bumping at the end is done only when we know there is some change.
That is the theory. But the practice is that we should, as you suggest,
reconsider the issue at the end but we don't because we all think we
already did it at the beginning. That considerably confuses the issue for
no real gain. During the development cycle the version number is pretty
irrelevant because it is more likely that the code is broken than that
there is a genuine library conflict that could be usefully resolved.
> The big question is whether a change in the API or a change in the code
> (recompile) is enough to bump that major version number. We always make
> some force-recompile change in the library in each release, don't we?
> Do we just bump the major in every major release?
The rules are pretty clear: If you change or remove an interface (= part
of the API) then you change the major, if you add an interface or
"improve" the code, change the minor. Whether we actually change the code
during a release cycle is something that is best determined *after* the
release cycle. Possibly we always do, but I wouldn't be surprised if some
library like pgeasy lay dormant for a while.
> I usually bumped the minor at the beginning because this allows beta
> testers to not have _extra_ versions of the library laying around, and
That doesn't make sense to me. Which extra versions?
--
Peter Eisentraut peter_e@gmx.net
