1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
For All Releases (major, minor, beta, RC)
================
* Release version number changes
o doc/bug.template
o bump Win32 interface version numbers
- src/include/pg_config.h.win32
- src/interfaces/libpq/libpq.rc.in
- src/port/win32ver.rc
o update doc/FAQ and doc/src/FAQ/FAQ.html
o copy FAQs from HEAD to top-most branch
o configure.in, and run autoconf or update configure (by packager)
* Release notes
o scan cvs logs, use pgcvslog and flags in comments
o update doc/src/sgml/release.sgml
o run spellchecker on result
o add SGML markup
* Update timezone data to match latest zic database (see src/timezone/README)
* Translation updates
Translations are kept in the project "pgtranslation" on PgFoundry.
1. Check out the messages module (of the right branch).
2. Check out the admin module.
3. Run "sh .../admin/cp-po .../messages .../pgsql
4. Commit.
For Major Releases
==================
(in addition to the above)
* Bump library versions, if appropriate (see below)
o src/interfaces/*/Makefile
o src/interfaces/*/*/Makefile
* Release notes
o check that dashed items from the TODO list are complete
o remove dashed TODO items
o group items into categories
o select major features
o select incompatibilities
o add documenation for items
* Documentation
document all new features
update help output from inside the programs
doc/src/sgml/ref manual pages
convert any literal "<" and ">" characters, use tools/find_gt_lt
* Ports
update config.guess and config.sub at the start of beta
update ports list in doc/src/sgml/installation.sgml
update platform-specific FAQ's, if needed
* Update inet/cidr data types with newest Bind patches
---------------------------------------------------------------------------
Library Version Changes
=======================
Major Version
=============
The major version number should be updated whenever the source of the
library changes to make it binary incompatible. Such changes include,
but are not 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.
4. 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.
Adding a new function would NOT force an increase in the major version
number. When the major version is increased all applications which
link to the library MUST be recompiled - this is not desirable. When
the major version is updated the minor version gets reset.
Minor Version
=============
The minor version number should be updated whenever the functionality
of the library has changed, typically and change in source code
between releases would mean an increase in the minor version number so
long as it does not require a major version increase.
Minimizing Changes
==================
When modifying public functions arguments, steps should 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 Kindness
|
