Author |
Message |
Peter Eisentra #1 / 11
|
 Shared library versions
We did not bump the shared library versions before the 7.1 release. Maybe we should do this before 7.1.2 goes out. --
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate
message can get through to the mailing list cleanly
|
Mon, 27 Oct 2003 03:00:45 GMT |
|
 |
Bruce Momji #2 / 11
|
 Shared library versions
Quote: > We did not bump the shared library versions before the 7.1 release. > Maybe we should do this before 7.1.2 goes out.
I thought I did that long ago for 7.1, or I should have anyway. I don't see the commits either. Seems we can't do it in a minor release. Will have to wait for 7.2, but since there really wasn't much API change in 7.1, I think we are OK. Not sure if we should update them if there are no API changes, or were there? -- Bruce Momjian | http://candle.pha.pa.us
+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command
|
Mon, 27 Oct 2003 03:17:54 GMT |
|
 |
The Hermit Hack #3 / 11
|
 Shared library versions
Quote:
> We did not bump the shared library versions before the 7.1 release. > Maybe we should do this before 7.1.2 goes out.
Ummm ... unless there are any changes that would require someone to recompile their apps between v7.1.1 and v7.1.2, I don't think so ... they we are just creating potential problems for those upgrading from v7.1/v7.1.1 to the latest stable, where there are no changes ... If we were to do it, it would have to be on the v7.x, not v7.x.y ... ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
|
Mon, 27 Oct 2003 03:29:25 GMT |
|
 |
Tom La #4 / 11
|
 Shared library versions
Quote:
>> We did not bump the shared library versions before the 7.1 release. >> Maybe we should do this before 7.1.2 goes out. > I thought I did that long ago for 7.1, or I should have anyway. I don't > see the commits either. Seems we can't do it in a minor release.
I agree, too late now. Isn't there a checklist someplace of things to do while preparing a release? "Check shared library version numbers" should be on it... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command
|
Mon, 27 Oct 2003 03:48:05 GMT |
|
 |
Peter Eisentra #5 / 11
|
 Shared library versions
Quote: The Hermit Hacker writes:
> > We did not bump the shared library versions before the 7.1 release. > > Maybe we should do this before 7.1.2 goes out. > Ummm ... unless there are any changes that would require someone to > recompile their apps between v7.1.1 and v7.1.2, I don't think so ... they > we are just creating potential problems for those upgrading from > v7.1/v7.1.1 to the latest stable, where there are no changes ...
I'm talking about the minor number. The only thing that effects is that executables would pick up the new version if they have the old one in the path as well, no potential problems. --
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
|
Mon, 27 Oct 2003 03:48:49 GMT |
|
 |
Bruce Momji #6 / 11
|
 Shared library versions
What we should have done is ask which API's changed for 7.1. I know I just changed the libpq++ API for 7.2. Quote:
> > > We did not bump the shared library versions before the 7.1 release. > > > Maybe we should do this before 7.1.2 goes out. > > I thought I did that long ago for 7.1, or I should have anyway. I don't > > see the commits either. Seems we can't do it in a minor release. Will > > have to wait for 7.2, but since there really wasn't much API change in > > 7.1, I think we are OK. Not sure if we should update them if there are > > no API changes, or were there? > IMHO, it should only be changed if there are incompatibilities between > releases ... we modify the API, mainly ... anything more then that, and > we're making ppl recompile to pull in libraries that only unlying code has > changed, but not the API ...
-- Bruce Momjian | http://candle.pha.pa.us
+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate
message can get through to the mailing list cleanly
|
Mon, 27 Oct 2003 03:51:27 GMT |
|
 |
The Hermit Hack #7 / 11
|
 Shared library versions
Quote:
> > We did not bump the shared library versions before the 7.1 release. > > Maybe we should do this before 7.1.2 goes out. > I thought I did that long ago for 7.1, or I should have anyway. I don't > see the commits either. Seems we can't do it in a minor release. Will > have to wait for 7.2, but since there really wasn't much API change in > 7.1, I think we are OK. Not sure if we should update them if there are > no API changes, or were there?
IMHO, it should only be changed if there are incompatibilities between releases ... we modify the API, mainly ... anything more then that, and we're making ppl recompile to pull in libraries that only unlying code has changed, but not the API ... ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
|
Mon, 27 Oct 2003 04:03:10 GMT |
|
 |
Bruce Momji #8 / 11
|
 Shared library versions
Quote:
> >> We did not bump the shared library versions before the 7.1 release. > >> Maybe we should do this before 7.1.2 goes out. > > I thought I did that long ago for 7.1, or I should have anyway. I don't > > see the commits either. Seems we can't do it in a minor release. > I agree, too late now. > Isn't there a checklist someplace of things to do while preparing a > release? "Check shared library version numbers" should be on it...
Yep, it is there in tools/RELEASE_CHANGES: * Version numbers configure.in doc/src/sgml/version.sgml bump interface version numbers ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ update src/interfaces/libpq/libpq.rc update /src/include/config.h.win32 -- Bruce Momjian | http://candle.pha.pa.us
+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)---------------------------
|
Mon, 27 Oct 2003 04:11:00 GMT |
|
 |
Peter Eisentra #9 / 11
|
 Shared library versions
Quote: The Hermit Hacker writes: > IMHO, it should only be changed if there are incompatibilities between > releases ... we modify the API, mainly ... anything more then that, and > we're making ppl recompile to pull in libraries that only unlying code has > changed, but not the API ...
ISTM that you should read up on shared library versioning. --
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
|
Mon, 27 Oct 2003 04:15:38 GMT |
|
 |
Trond Eivind Glomsr #10 / 11
|
 Shared library versions
Quote:
> The Hermit Hacker writes: > > IMHO, it should only be changed if there are incompatibilities between > > releases ... we modify the API, mainly ... anything more then that, and > > we're making ppl recompile to pull in libraries that only unlying code has > > changed, but not the API ... > ISTM that you should read up on shared library versioning.
I second that... if new functionality is added, bump the minor. If functionality changes or is removed, bump the major. -- Trond Eivind Glomsr?d Red Hat, Inc. ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
|
Mon, 27 Oct 2003 04:35:54 GMT |
|
 |
The Hermit Hack #11 / 11
|
 Shared library versions
Quote:
> I'm talking about the minor number. The only thing that effects is > that executables would pick up the new version if they have the old > one in the path as well, no potential problems.
Okay, but, what does that buy you? One overwrites the old library, the other creates one that will over-ride the old library ... either way, you are using the new library, no? ---------------------------(end of broadcast)---------------------------
|
Mon, 27 Oct 2003 07:55:00 GMT |
|
|