Обсуждение: Let's make a new release
(resending from correct address, sorry for possible duplicate..) We're way overdue for a new psqlodbc release. Hiroshi: would you have the time to make a release soon? If not, I can take a shot at it, but I've never done that before. In any case, I'm going to start writing the release notes. I propose that we call the release 09.05.0100, and make the actual release in the next two weeks or so. I don't have the infrastructure at hand to build the Windows binaries, so if I have to make the release, I'm only going to create the tag to the git repository, and a source tarball. Hopefully someone else will build the binaries later. I can also ask around inside Pivotal (my current employer) if someone there would like to pick up the task to produce binaries, but if not, let's make a source release anyway. Unless you, Hiroshi, have the time to do that? - Heikki
I'm all for a new release, but aren't we skipping a version number (09.04.0100)? I thought the 09.04 part would mean it was compiled using lib files from PostgreSQL 9.4? So would the binaries then be compiled using libs from PostgreSQL 9.5 (beta)? Or does that not have anything at all to do with it? I do know that the psqlodbc versions are independent of the PostgreSQL version numbers, though it probably "looks" better to have them line-up with the current server version. Thanks...jack -- View this message in context: http://postgresql.nabble.com/Let-s-make-a-new-release-tp5871928p5872005.html Sent from the PostgreSQL - odbc mailing list archive at Nabble.com.
On Thu, Oct 29, 2015 at 3:06 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > (resending from correct address, sorry for possible duplicate..) > > We're way overdue for a new psqlodbc release. Hiroshi: would you have the > time to make a release soon? If not, I can take a shot at it, but I've never > done that before. +1. > In any case, I'm going to start writing the release notes. I propose that we > call the release 09.05.0100, and make the actual release in the next two > weeks or so. I don't have the infrastructure at hand to build the Windows > binaries, so if I have to make the release, I'm only going to create the tag > to the git repository, and a source tarball. Hopefully someone else will > build the binaries later. I can also ask around inside Pivotal (my current > employer) if someone there would like to pick up the task to produce > binaries, but if not, let's make a source release anyway. Unless you, > Hiroshi, have the time to do that? I could try to have a shot with my Win7 box, though I am not sure what are the build options that we should invoke. I am sure that we should have a build with OpenSSL and libpq (which is now mandatory), and that nmake is not the way to go. Hence we should generate the msis with .\BuildAll and have all the Release builds? And we should provide AMD64Release, AMD64ANSIRelease, Release and MultibyteRelease as a set, no? -- Michael
Michael Paquier wrote > I could try to have a shot with my Win7 box, though I am not sure what > are the build options that we should invoke. I am sure that we should > have a build with OpenSSL and libpq (which is now mandatory), and that > nmake is not the way to go. Hence we should generate the msis with > .\BuildAll and have all the Release builds? And we should provide > AMD64Release, AMD64ANSIRelease, Release and MultibyteRelease as a set, > no? I tried this with the psqlodbc\installer\buildInstallers.ps1 PowerShell script using a Windows 8.1 64-bit virtual machine, with the 32 and 64-bit version of PostgreSQL 9.4.5 installed. I had to make the changes in the attached patch (libintl.dll is no longer in the 9.4+ PostgreSQL binary distribution--intl.dll is used instead). I called this version 09.04.0100, but if we want to go ahead and use 9.5 beta1 and release it as 09.05.0100 then I could try it with the necessary files from that version. The created psqlodbc-setup.exe file seems to work fine--I've tested it on Windows 7 64 bit, Windows 8.1 64 bit, and Windows XP (32-bit). ...jack version_change.patch <http://postgresql.nabble.com/file/n5872270/version_change.patch> -- View this message in context: http://postgresql.nabble.com/Let-s-make-a-new-release-tp5871928p5872270.html Sent from the PostgreSQL - odbc mailing list archive at Nabble.com.
On Mon, Nov 2, 2015 at 9:05 AM, ljwilson <ljwilson@digitalav.com> wrote: > Michael Paquier wrote >> I could try to have a shot with my Win7 box, though I am not sure what >> are the build options that we should invoke. I am sure that we should >> have a build with OpenSSL and libpq (which is now mandatory), and that >> nmake is not the way to go. Hence we should generate the msis with >> .\BuildAll and have all the Release builds? And we should provide >> AMD64Release, AMD64ANSIRelease, Release and MultibyteRelease as a set, >> no? > > I tried this with the psqlodbc\installer\buildInstallers.ps1 PowerShell > script using a Windows 8.1 64-bit virtual machine, with the 32 and 64-bit > version of PostgreSQL 9.4.5 installed. I had to make the changes in the > attached patch (libintl.dll is no longer in the 9.4+ PostgreSQL binary > distribution--intl.dll is used instead). Is that EDB installer? Community scripts still use libintl.lib when nls is enabled. > I called this version 09.04.0100, > but if we want to go ahead and use 9.5 beta1 and release it as 09.05.0100 > then I could try it with the necessary files from that version. > The created psqlodbc-setup.exe file seems to work fine--I've tested it on > Windows 7 64 bit, Windows 8.1 64 bit, and Windows XP (32-bit). This brings another question: from which source was libpq taken from for the previous released versions of the driver? I would assume that this was the EDB installer, but it would be good to be sure. Saito-san and Inoue-san, you are in CC. Could you share your wisdom on this matter? -- Michael
Michael Paquier wrote > Is that EDB installer? Community scripts still use libintl.lib when > nls is enabled. Yes, I used binaries from the EDB Installer. ...jack -- View this message in context: http://postgresql.nabble.com/Let-s-make-a-new-release-tp5871928p5872331.html Sent from the PostgreSQL - odbc mailing list archive at Nabble.com.
Hi Michael, Jack and all, Until pretty recently, I was unavailable due to my disease.. I am back now but would not be so active as before. I didn't package the installer by myself but I believe it uses libpq from EDB. One thing I'd like to point out is about MSVC runtime library. The installer installs MSVC runtime library msvcrxxx.dll used by the driver but don't install the one used by libpq. If we use different version of MSVC runtime, we have to add an procedure to install MSVC runtime used by libpq. regards, Hiroshi Inoue On 2015/11/02 15:52, Michael Paquier wrote: > On Mon, Nov 2, 2015 at 9:05 AM, ljwilson <ljwilson@digitalav.com> wrote: >> Michael Paquier wrote >>> I could try to have a shot with my Win7 box, though I am not sure what >>> are the build options that we should invoke. I am sure that we should >>> have a build with OpenSSL and libpq (which is now mandatory), and that >>> nmake is not the way to go. Hence we should generate the msis with >>> .\BuildAll and have all the Release builds? And we should provide >>> AMD64Release, AMD64ANSIRelease, Release and MultibyteRelease as a set, >>> no? >> I tried this with the psqlodbc\installer\buildInstallers.ps1 PowerShell >> script using a Windows 8.1 64-bit virtual machine, with the 32 and 64-bit >> version of PostgreSQL 9.4.5 installed. I had to make the changes in the >> attached patch (libintl.dll is no longer in the 9.4+ PostgreSQL binary >> distribution--intl.dll is used instead). > Is that EDB installer? Community scripts still use libintl.lib when > nls is enabled. > >> I called this version 09.04.0100, >> but if we want to go ahead and use 9.5 beta1 and release it as 09.05.0100 >> then I could try it with the necessary files from that version. >> The created psqlodbc-setup.exe file seems to work fine--I've tested it on >> Windows 7 64 bit, Windows 8.1 64 bit, and Windows XP (32-bit). > This brings another question: from which source was libpq taken from > for the previous released versions of the driver? I would assume that > this was the EDB installer, but it would be good to be sure. Saito-san > and Inoue-san, you are in CC. Could you share your wisdom on this > matter?
Hi Hiroshi! On 11/04/2015 05:22 AM, Inoue, Hiroshi wrote: > Hi Michael, Jack and all, > > Until pretty recently, I was unavailable due to my disease.. > I am back now but would not be so active as before. Good to see you back, hope you're doing better.. I wrote release notes for the upcoming release, see attached. I did not mention commits that have no user-visible effect, like code cleanup, refactoring, and adding test cases. How does it look? I plan to still get a couple of small things committed before we tag the release, in particular the SQLTables() support for materialized views and foreign tables (http://www.postgresql.org/message-id/CAJ3aXhoNRbNLH8NqqNYVFNs-OO3c5DUTMXNJ9XDz_iQv=Gh6KA@mail.gmail.com) and the fix for the DATA_AT_EXEC with large objects bug (http://www.postgresql.org/message-id/561F954E.7020808@serena.com). - Heikki
Вложения
Hi All. I'd reconfirm it and work on a weekend. thankful for your patience... On 2015/11/04 12:22, Inoue, Hiroshi wrote: > > Until pretty recently, I was unavailable due to my disease.. > I am back now but would not be so active as before. I seem to have to continue this.!:-) Regard, Hiroshi Saito On 2015/11/10 3:02, Heikki Linnakangas wrote: > Hi Hiroshi! > > On 11/04/2015 05:22 AM, Inoue, Hiroshi wrote: >> Hi Michael, Jack and all, >> >> Until pretty recently, I was unavailable due to my disease.. >> I am back now but would not be so active as before. > > Good to see you back, hope you're doing better.. > > I wrote release notes for the upcoming release, see attached. I did not > mention commits that have no user-visible effect, like code cleanup, > refactoring, and adding test cases. How does it look? > > I plan to still get a couple of small things committed before we tag the > release, in particular the SQLTables() support for materialized views > and foreign tables > (http://www.postgresql.org/message-id/CAJ3aXhoNRbNLH8NqqNYVFNs-OO3c5DUTMXNJ9XDz_iQv=Gh6KA@mail.gmail.com) > and the fix for the DATA_AT_EXEC with large objects bug > (http://www.postgresql.org/message-id/561F954E.7020808@serena.com). > > - Heikki >
On Tue, Nov 10, 2015 at 11:25 PM, Hiroshi Saito <hiroshi@winpg.jp> wrote: > > Hi All. > > I'd reconfirm it and work on a weekend. > thankful for your patience... > > On 2015/11/04 12:22, Inoue, Hiroshi wrote: >> >> Until pretty recently, I was unavailable due to my disease.. >> I am back now but would not be so active as before. > > I seem to have to continue this.!:-) Btw, could it be possible to put in the docs more information about the way a release is done for Windows. Particularly it would be good to know which version of Postgres is used as a base, now that linking to libpq is mandatory for the build, and how are generated the builds. I would assume nmake was not used and that build is generated with following winbuild/readme.txt using BuildAll.bat, but it would be good to get some confirmation.. -- Michael
I also struggled with this - the Powershell script worked well for building the DLLs but I couldn't get the installer preparation working.
On 2015/11/04 12:22, Inoue, Hiroshi wrote: > Hi Michael, Jack and all, > > Until pretty recently, I was unavailable due to my disease.. > I am back now but would not be so active as before. > > I didn't package the installer by myself but I believe it uses libpq > from EDB. > > One thing I'd like to point out is about MSVC runtime library. > The installer installs MSVC runtime library msvcrxxx.dll used by the > driver > but don't install the one used by libpq. If we use different version > of MSVC > runtime, we have to add an procedure to install MSVC runtime used by > libpq. I pushed some changes about building installers. Instead of describing fixed dlls in the .wxs file, automatically detect necessary libpq related dlls and install them. Please try. regards, Hiroshi Inoue
Hiroshi, I just downloaded a clean tree of the latest from git (d095f7e99560052f3923d6fe693979db4c83d6c0) and was able to build the installer which includes both 32-bit and 64-bit just fine. I'm building on a Windows 8.1 VMWare Virtual Machine with Visual Studio 2013 against PostgreSQL 9.4.5 with the PowerShell scripts. I get 4 compiler warnings (the same two for both 32-bit and 64-bit): ..\convert.c(790): warning C4056: overflow in floating-point constant arithmetic [C:\psqlodbc\winbuild\psqlodbc.vcxproj] ..\execute.c(745): warning C4101: 'ptr' : unreferenced local variable [C:\psqlodbc\winbuild\psqlodbc.vcxproj] The ptr one is left over from a recent patch (bb468cbcaf3912b0093178036505587ac0f0158b)--I think the overflow one has been there for a while. Thanks...jack -- View this message in context: http://postgresql.nabble.com/Let-s-make-a-new-release-tp5871928p5874720.html Sent from the PostgreSQL - odbc mailing list archive at Nabble.com.