Thread: Re: Revamped runtime vs. Version number
+1 … what roughly would be the release date? (Asking only because my beginner SQL book, which uses pgAdmin, is publishing in April and we are in the final proofreads now.)
Anthony DeBarros
On February 1, 2018 at 10:09:46 AM, Paolo Saudin (paolosaudin@gmail.com) wrote:
As Melvin, I am too in favor of "version number to 3.0 for the next release".
Paolo
2018-02-01 16:00 GMT+01:00 Ashesh Vashi <ashesh.vashi@enterprisedb.com>:
On Feb 1, 2018 8:15 PM, "Dave Page" <dpage@pgadmin.org> wrote:So there's been nothing but positive feedback about the PoC revamped runtime I asked folks on the lists to test. Thank you to everyone that did so.With that in mind, I think we should use that in the next version and moving forwards, and bump the version number to 3.0 for the next release.+1Does anyone object to that plan?Nope.-- Thanks, AsheshFYI, since the original PoC, I've made the following additional changes:- Move to using a shared memory interlock to ensure only a single instance (per user, per copy of the executable) is run. This means if you have multiple copies of pgAdmin installed, they won't interact with each other, but a single copy is limited to a single instance per user.- Add a log viewer. If startup fails (or other errors occur), the Python logs can now easily be viewed in the runtime.- Tidied up the configuration dialogue.- Added a config option to allow an alternate command to be run rather than executing the default browser. This allows any browser to be configured, using different profiles etc, as possible when launching on the command line.- Made startup more robust so config options can be corrected without restarts if needed, and failures can be detected much more quickly.- Cleaned up a bunch of redundant code.--Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Feb 1, 2018 at 3:21 PM, Anthony DeBarros <adebarros@gmail.com> wrote:
+1 … what roughly would be the release date? (Asking only because my beginner SQL book, which uses pgAdmin, is publishing in April and we are in the final proofreads now.)
Maybe in a couple of weeks. I don't have a specific plan yet though - we've been working on accessibility features for the last few weeks, and I want to get them completed which is taking more effort than expected.
Anthony DeBarrosOn February 1, 2018 at 10:09:46 AM, Paolo Saudin (paolosaudin@gmail.com) wrote:
As Melvin, I am too in favor of "version number to 3.0 for the next release".Paolo2018-02-01 16:00 GMT+01:00 Ashesh Vashi <ashesh.vashi@enterprisedb.com>: On Feb 1, 2018 8:15 PM, "Dave Page" <dpage@pgadmin.org> wrote:So there's been nothing but positive feedback about the PoC revamped runtime I asked folks on the lists to test. Thank you to everyone that did so.With that in mind, I think we should use that in the next version and moving forwards, and bump the version number to 3.0 for the next release.+1Does anyone object to that plan?Nope.-- Thanks, AsheshFYI, since the original PoC, I've made the following additional changes:- Move to using a shared memory interlock to ensure only a single instance (per user, per copy of the executable) is run. This means if you have multiple copies of pgAdmin installed, they won't interact with each other, but a single copy is limited to a single instance per user.- Add a log viewer. If startup fails (or other errors occur), the Python logs can now easily be viewed in the runtime.- Tidied up the configuration dialogue.- Added a config option to allow an alternate command to be run rather than executing the default browser. This allows any browser to be configured, using different profiles etc, as possible when launching on the command line.- Made startup more robust so config options can be corrected without restarts if needed, and failures can be detected much more quickly.- Cleaned up a bunch of redundant code.--Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Feb 1, 2018 at 3:21 PM, Anthony DeBarros <adebarros@gmail.com> wrote:
+1 … what roughly would be the release date? (Asking only because my beginner SQL book, which uses pgAdmin, is publishing in April and we are in the final proofreads now.)
Maybe in a couple of weeks. I don't have a specific plan yet though - we've been working on accessibility features for the last few weeks, and I want to get them completed which is taking more effort than expected.
Anthony DeBarrosOn February 1, 2018 at 10:09:46 AM, Paolo Saudin (paolosaudin@gmail.com) wrote:
As Melvin, I am too in favor of "version number to 3.0 for the next release".Paolo2018-02-01 16:00 GMT+01:00 Ashesh Vashi <ashesh.vashi@enterprisedb.com>: On Feb 1, 2018 8:15 PM, "Dave Page" <dpage@pgadmin.org> wrote:So there's been nothing but positive feedback about the PoC revamped runtime I asked folks on the lists to test. Thank you to everyone that did so.With that in mind, I think we should use that in the next version and moving forwards, and bump the version number to 3.0 for the next release.+1Does anyone object to that plan?Nope.-- Thanks, AsheshFYI, since the original PoC, I've made the following additional changes:- Move to using a shared memory interlock to ensure only a single instance (per user, per copy of the executable) is run. This means if you have multiple copies of pgAdmin installed, they won't interact with each other, but a single copy is limited to a single instance per user.- Add a log viewer. If startup fails (or other errors occur), the Python logs can now easily be viewed in the runtime.- Tidied up the configuration dialogue.- Added a config option to allow an alternate command to be run rather than executing the default browser. This allows any browser to be configured, using different profiles etc, as possible when launching on the command line.- Made startup more robust so config options can be corrected without restarts if needed, and failures can be detected much more quickly.- Cleaned up a bunch of redundant code.--Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company