2
configure.in and configure
3
bump interface version numbers
4
o src/interfaces/*/Makefile
5
o src/interfaces/libpq/libpq.rc (update for minor release)
6
o src/include/pg_config.h.win32 (update for minor release)
9
update doc/src/sgml/release.sgml and generate HISTORY
12
document all new features
13
update help output from inside the programs
14
doc/src/sgml/ref manual pages
17
update ports list in doc/src/sgml/installation.sgml
19
platform-specific FAQ's, if needed
24
* Update pg_upgrade to handle new version, or disable
26
* Update copyright year?
29
---------------------------------------------------------------------------
31
Library Version Changes
32
=======================
37
The major version number should be updated whenever the source of the
38
library changes to make it binary incompatible. Such changes include,
39
but are not limited to:
41
1. Removing a public function or structure (or typedef, enum, ...)
43
2. Modifying a public functions arguments.
45
3. Removing a field from a public structure.
47
4. Adding a field to a public structure, unless steps have been
48
previously taken to shield users from such a change, for example by
49
such structures only ever being allocated/instantiated by a library
50
function which would give the new field a suitable default value.
52
Adding a new function would NOT force an increase in the major version
53
number. When the major version is increased all applications which
54
link to the library MUST be recompiled - this is not desirable. When
55
the major version is updated the minor version gets reset.
60
The minor version number should be updated whenever the functionality
61
of the library has changed, typically and change in source code
62
between releases would mean an increase in the minor version number so
63
long as it does not require a major version increase.
68
When modifying public functions arguments, steps should be taken to
69
maintain binary compatibility across minor PostgreSQL releases (e.g. the
70
7.2 series, the 7.3 series, the 7.4/8.0 series). Consider the following
73
void print_stuff(int arg1, int arg2)
75
printf("stuff: %d %d\n", arg1, arg2);
78
If we wanted to add a third argument:
80
void print_stuff(int arg1, int arg2, int arg3)
82
printf("stuff: %d %d %d\n", arg1, arg2, arg3);
85
Then doing it like this:
87
void print_stuff2(int arg1, int arg2, int arg3)
89
printf("stuff: %d %d %d\n", arg1, arg2, arg3);
92
void print_stuff(int arg1, int arg2)
94
print_stuff(arg1, arg2, 0);
97
would maintain binary compatibility. Obviously this would add a fair
98
bit of cruft if used extensively, but considering the changes between
99
minor versions would probably be worthwhile to avoid bumping library
100
major version. Naturally in the next major version print_stuff() would
101
assume the functionality and arguments of print_stuff2().