Guys,
Some further comments on bumbing the major version number which aren't
so cut-n-dry...
Lee Kindness writes:
> The major version number should be updated whenever the source of the
> library changes to make it binary incompatible. Such changes include,
> but limited to:
>
> 1. Removing a public function or structure (or typedef, enum, ...)
>
> 2. Modifying a public functions arguments.
>
> 3. Removing a field from a public structure.
>
> 3. Adding a field to a public structure, unless steps have been
> previously taken to shield users from such a change, for example by
> such structures only ever being allocated/instantiated by a library
> function which would give the new field a suitable default value.
For #2 steps could be taken to maintain binary compatibility across
minor PostgreSQL releases (e.g. the 7.2 series, the 7.3 series, the
7.4/8.0 series). Consider the following function
void print_stuff(int arg1, int arg2)
{
printf("stuff: %d %d\n", arg1, arg2);
}
If we wanted to add a third argument:
void print_stuff(int arg1, int arg2, int arg3)
{
printf("stuff: %d %d %d\n", arg1, arg2, arg3);
}
Then doing it like this:
void print_stuff2(int arg1, int arg2, int arg3)
{
printf("stuff: %d %d %d\n", arg1, arg2, arg3);
}
void print_stuff(int arg1, int arg2)
{
print_stuff(arg1, arg2, 0);
}
would maintain binary compatibility. Obviously this would add a fair
bit of cruft if used extensively, but considering the changes between
minor versions would probably be worthwhile to avoid bumping library
major version. Naturally in the next major version print_stuff() would
assume the functionality and arguments of print_stuff2().
Lee.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
