1 For All Releases (major, minor, beta, RC)
4 * Release version number changes
5 o update doc/FAQ and doc/src/FAQ/FAQ.html
6 o copy FAQs from HEAD to top-most branch
7 o run src/tools/version_stamp.pl, then run autoconf
11 o scan cvs logs, use pgcvslog and flags in comments
12 o update doc/src/sgml/release.sgml
13 o run spellchecker on result
15 o check if 'gmake HISTORY.html' works for <link>s
17 * Update timezone data to match latest zic database (see src/timezone/README)
20 Translations are kept in the project "pgtranslation" on PgFoundry.
21 1. Check out the messages module (of the right branch).
22 2. Check out the admin module.
23 3. Run "sh .../admin/cp-po .../messages .../pgsql
29 (in addition to the above)
31 * Bump minor library versions, major if appropriate (see below)
32 o src/interfaces/*/Makefile
33 o src/interfaces/*/*/Makefile
36 o check that dashed items from the TODO list are complete
37 o remove dashed TODO items
38 o group items into categories
39 o select major features
40 o select incompatibilities
41 o add documentation for items
44 o document all new features
45 o update help output from inside the programs
46 o doc/src/sgml/ref manual pages
47 o convert any literal "<" and ">" characters, use tools/find_gt_lt
50 o update config.guess and config.sub at the start of beta
51 o update ports list in doc/src/sgml/installation.sgml
52 o update platform-specific FAQ's, if needed
54 * Update inet/cidr data types with newest Bind patches
57 Starting a New Development Cycle
58 ================================
60 * Create a branch in CVS for maintenance of the previous release
62 * Increment the major version number in src/tools/version_stamp.pl
64 * Run "src/tools/version_stamp.pl devel", then run autoconf
67 Creating Back-Branch Release Notes
68 ==================================
70 * Do 'cvs log' on each back-branch and run pgcvslog
72 * Edit and create SGML markup for the most recent branch
74 * Make copies of the SGML for each branch, then remove items
75 that do not apply based on cvs logs for that branch
77 * Copy the SGML for each branch into release.sgml in CVS HEAD
79 * Use src/tools/major_release_split to create a release.sgml for
80 each branch and copy them to the branch's CVS
83 ---------------------------------------------------------------------------
85 Library Version Changes
86 =======================
91 The major version number should be updated whenever the source of the
92 library changes to make it binary incompatible. Such changes include,
93 but are not limited to:
95 1. Removing a public function or structure (or typedef, enum, ...)
97 2. Modifying a public functions arguments.
99 3. Removing a field from a public structure.
101 4. Adding a field to a public structure, unless steps have been
102 previously taken to shield users from such a change, for example by
103 such structures only ever being allocated/instantiated by a library
104 function which would give the new field a suitable default value.
106 Adding a new function should NOT force an increase in the major version
107 number. (Packagers will see the standard minor number update and install
108 the new library.) When the major version is increased all applications
109 which link to the library MUST be recompiled - this is not desirable. When
110 the major version is updated the minor version gets reset.
115 The minor version number should be updated whenever the functionality of
116 the library has changed, typically a change in source code between releases
117 would mean an increase in the minor version number so long as it does not
118 require a major version increase.
120 Given that we make at least minor changes to our libraries in every major
121 PostgreSQL version, we always bump all minor library version numbers at the
122 start of each development cycle as a matter of policy.
127 When modifying public functions arguments, steps should be taken to
128 maintain binary compatibility across minor PostgreSQL releases (e.g. the
129 7.2 series, the 7.3 series, the 7.4/8.0 series). Consider the following
132 void print_stuff(int arg1, int arg2)
134 printf("stuff: %d %d\n", arg1, arg2);
137 If we wanted to add a third argument:
139 void print_stuff(int arg1, int arg2, int arg3)
141 printf("stuff: %d %d %d\n", arg1, arg2, arg3);
144 Then doing it like this:
146 void print_stuff2(int arg1, int arg2, int arg3)
148 printf("stuff: %d %d %d\n", arg1, arg2, arg3);
151 void print_stuff(int arg1, int arg2)
153 print_stuff(arg1, arg2, 0);
156 would maintain binary compatibility. Obviously this would add a fair
157 bit of cruft if used extensively, but considering the changes between
158 minor versions would probably be worthwhile to avoid bumping library
159 major version. Naturally in the next major version print_stuff() would
160 assume the functionality and arguments of print_stuff2().