Anything else to add?

@charmander thanks for putting the 8.0 milestone on a few of the issues. Anything else that comes to mind you want to break in the newest release? I want to keep churn somewhat down on the 8.0 release…one of the main things I want to do is drop support for all versions of node earlier than any active LTS versions. There was some talk about making BigInt support opt-in in 8.0…but since it’ll be opt-in for now I don’t think we need to land it directly on the major version bump.

It looks like 8.0 is going end of life in like…3 days! So I think we could drop official support for anything earlier than node 10 which is the currently oldest LTS version…what do you think? reference

Now that this is a monorepo with most of the main dependent modules included I can have a much easier time doing sweeping changes to the internal APIs and weird timing behaviors. I want to hit the entire monorepo w/ a prettier format & enforce prettier formatting via eslint because the lint rules haven’t been consistent between all the repos…and the tests inside pg (some of which are very old) haven’t been linted at all…so…I’m going to fix all the lint stuff before 8.0 just to keep things slightly more organized.

Thanks again for all your help & support.

[brianc]

Why wait for version 9?

Well…two reasons. 1) it’s a lot of work & I don’t want to delay 8 for it…8’s already been held back for quite a while as we were letting some breaking changes kinda “pile up” for it. and 2) It’s going to be a big change & I’d like to release it and nothing else so the upgrade guide is clear and its not “oh we deprecated this, that, this one thing changed, also: rewrote EVERYTHING” just to keep issue triage after the fact (hopefully there aren’t any…but you never know) a bit easier to do. Plus I dunno…this module is really heavily used in a lot of places & I don’t subscribe to the “move fast and break things” mindset w/ it at all…rather go a bit on the slow side than fast side…but we’ll get there! It’s always been more of a marathon than a sprint kinda mindset for me…helps me not burn out. 😄

[dpkirchner]

If https://github.com/brianc/node-pg-pool/pull/119 (referenced in another comment) can’t be merged, moving the client.release = ...[0] call up so it’s just before the emit('connect', client) call would allow us to implement our own release logic (saving the error emission and using it in our overridden release call, for example) before the client is returned to our code. This might be a breaking change, but I kind of doubt there’s a lot of people that rely on release being set only after connect is emitted.

[0] https://github.com/brianc/node-postgres/blob/master/packages/pg-pool/index.js#L255