Re: [HACKERS] Version numbers (was Re: [PATCHES] Several libpgtcl fixes)
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Version numbers (was Re: [PATCHES] Several libpgtcl fixes) |
Дата | |
Msg-id | 199809210325.XAA17970@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Version numbers (was Re: [PATCHES] Several libpgtcl fixes) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> BTW, I bumped the package version number from 1.2 to 1.3. Is this > >> premature? Does someone run around and do that routinely before > >> each pgsql release? > > > What verison numbers? I didn't know we had any version numbers excepct > > PG_VERSION, and I update that one > > There are version numbers all over the place in the various frontend > libraries. The particular one I was speaking of was libpgtcl's number > as seen by the Tcl "package require" command. However, we also need > a strategy for dealing with the shared library version numbering of > libpq, libpgtcl, and anything else that is compilable as a shared lib > (is libpq++?). I think that the perl5 interface also has some kind of > version number that's seen by Perl's package version control. > > Making all these numbers match PG_VERSION would probably be a loser, > because they generally have semantics of their own: a shlib major > version number indicates whether you can expect to use it with an > existing application without relinking, for example. You want to bump > a shlib's version number when its API changes, not when the backend > changes. Therefore, each one of these libraries requires individual > attention to the version number :-( > > I think that it would be a good idea to have as part of the standard > pre-release checklist (there is one, no?) an item "what should we do > to the version numbers of libraries a,b,c,d,..." pgsql/src/tools/RELEASE_CHANGES is the file that shows the changes required. > While we're on the subject, I was going to propose bumping the shlib > version number of libpq itself from 1.0 to 2.0 for this release, > because (a) I don't think it's entirely binary compatible with the > previous libpq release (depends on whether people were touching the > PGconn struct directly...) and (b) people might want to keep around both > libpq 1.0 and 2.0 to talk to backends of different vintages. I'm not > sure whether any of the other frontend libs need a major version bump. Not sure how to handle these. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 http://www.op.net/~candle | (610) 353-9879(w) + If your life is a hard drive, | (610) 853-3000(h) + Christ can be your backup. |
В списке pgsql-hackers по дате отправления: