2006-11-24 18:03:50 +01:00
|
|
|
For All Releases (major, minor, beta, RC)
|
|
|
|
================
|
|
|
|
|
|
|
|
* Release version number changes
|
2007-12-13 03:02:20 +01:00
|
|
|
o doc/bug.template (beta)
|
2006-02-12 18:23:31 +01:00
|
|
|
o bump Win32 interface version numbers
|
2007-12-13 03:02:20 +01:00
|
|
|
- src/include/pg_config.h.win32
|
|
|
|
(string and integer versions) (beta)
|
2006-02-12 18:23:31 +01:00
|
|
|
- src/interfaces/libpq/libpq.rc.in
|
2007-01-05 21:54:43 +01:00
|
|
|
(pre-8.0 had just libpq.rc)
|
2006-02-12 18:23:31 +01:00
|
|
|
- src/port/win32ver.rc
|
|
|
|
o update doc/FAQ and doc/src/FAQ/FAQ.html
|
2006-10-10 02:30:32 +02:00
|
|
|
o copy FAQs from HEAD to top-most branch
|
2007-12-13 03:02:20 +01:00
|
|
|
o configure.in, and run autoconf or update configure
|
|
|
|
(by packager) (beta)
|
2004-12-16 23:11:06 +01:00
|
|
|
|
2000-11-24 19:28:20 +01:00
|
|
|
* Release notes
|
2004-12-16 23:11:06 +01:00
|
|
|
o scan cvs logs, use pgcvslog and flags in comments
|
|
|
|
o update doc/src/sgml/release.sgml
|
|
|
|
o run spellchecker on result
|
2006-11-24 18:03:50 +01:00
|
|
|
o add SGML markup
|
2007-04-20 17:47:08 +02:00
|
|
|
o check if 'gmake HISTORY.html' works for <link>s
|
2006-11-24 18:03:50 +01:00
|
|
|
|
|
|
|
* 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
|
2007-01-06 16:18:03 +01:00
|
|
|
o update ecpg regression expected files for new library number
|
2006-11-24 18:03:50 +01:00
|
|
|
|
|
|
|
* Release notes
|
2004-12-16 23:11:06 +01:00
|
|
|
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
|
2005-08-24 21:34:34 +02:00
|
|
|
o add documenation for items
|
2000-11-24 19:28:20 +01:00
|
|
|
|
|
|
|
* Documentation
|
2004-12-16 23:11:06 +01:00
|
|
|
document all new features
|
|
|
|
update help output from inside the programs
|
|
|
|
doc/src/sgml/ref manual pages
|
2005-01-23 01:30:59 +01:00
|
|
|
convert any literal "<" and ">" characters, use tools/find_gt_lt
|
2000-11-24 19:28:20 +01:00
|
|
|
|
|
|
|
* Ports
|
2004-12-16 23:11:06 +01:00
|
|
|
update config.guess and config.sub at the start of beta
|
|
|
|
update ports list in doc/src/sgml/installation.sgml
|
2005-05-09 01:34:15 +02:00
|
|
|
update platform-specific FAQ's, if needed
|
2000-11-24 19:28:20 +01:00
|
|
|
|
2005-02-02 17:58:52 +01:00
|
|
|
* Update inet/cidr data types with newest Bind patches
|
|
|
|
|
2002-12-14 20:45:46 +01:00
|
|
|
|
2007-09-12 05:21:20 +02:00
|
|
|
Creating Back-Branch Release Notes
|
|
|
|
==================================
|
2007-09-12 21:27:16 +02:00
|
|
|
|
2007-09-12 05:21:20 +02:00
|
|
|
* Do 'cvs log' on each back-branch and run pgcvslog
|
|
|
|
|
|
|
|
* Edit and create SGML markup for the most recent branch
|
|
|
|
|
|
|
|
* Make copies of the SGML for each branch, then remove items
|
|
|
|
that do not apply based on cvs logs for that branch
|
|
|
|
|
|
|
|
* Copy the SGML for each branch into release.sgml in CVS HEAD
|
|
|
|
|
|
|
|
* Copy CVS HEAD release.sgml to each branch and trim off the top
|
|
|
|
part that doesn't apply for each branch
|
|
|
|
|
|
|
|
|
2002-12-14 20:45:46 +01:00
|
|
|
---------------------------------------------------------------------------
|
|
|
|
|
2003-07-23 06:08:44 +02:00
|
|
|
Library Version Changes
|
|
|
|
=======================
|
|
|
|
|
|
|
|
Major Version
|
|
|
|
=============
|
2002-12-14 20:45:46 +01:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2003-01-11 05:58:44 +01:00
|
|
|
4. Adding a field to a public structure, unless steps have been
|
2002-12-14 20:45:46 +01:00
|
|
|
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.
|
|
|
|
|
2007-09-29 14:19:16 +02:00
|
|
|
Adding a new function should NOT force an increase in the major version
|
|
|
|
number. (Packagers will see the standard minor number update and install
|
|
|
|
the new library.) When the major version is increased all applications
|
|
|
|
which link to the library MUST be recompiled - this is not desirable. When
|
2002-12-14 20:45:46 +01:00
|
|
|
the major version is updated the minor version gets reset.
|
|
|
|
|
|
|
|
Minor Version
|
|
|
|
=============
|
|
|
|
|
2007-09-29 14:19:16 +02:00
|
|
|
The minor version number should be updated whenever the functionality of
|
|
|
|
the library has changed, typically a 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.
|
2002-12-14 20:45:46 +01:00
|
|
|
|
|
|
|
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
|