5.2 breaking changes

[sibedge]

5.2 broke my tests all over the place, with changes not documented anywhere.

My test errors show that now when we call pg.connect, the library modifies the original connection object.

I think I'm just the first one running into this, and there will be more.

[brianc]

That's correct, I modify the original object attaching a "release" method.
I'm fine to bump major version if it's a breaking change of a public
interface, but the behavior is the same and the public interface didn't
change. curious: why are you dependent on the actual object not being
modified? Feels like thats an internal sorta thing to look at.

On Tuesday, June 21, 2016, sibedge notifications@github.com wrote:

5.2 broke my tests all over the place, with changes not documented
anywhere.

My test errors show that now when we call pg.connect, the library
modifies the original object.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1059, or mute the thread
https://github.com/notifications/unsubscribe/AADDoc3vyJKYNo-Gmg936EaOVqTGox0Gks5qOJTjgaJpZM4I7VYc
.

[brianc]

Thinking about it a bit, there were some internal APIs I found documented w/o my knowing about on the wiki. I did remove those APIs. I've unpublished pg@5.2.0 since it's only been out a bit & will republish it at pg@6.0.0 with a bit more documentation coverage about what has changed.

I'd still like to understand what you were testing & how it broke so I can make sure to cover that in the documentation.

[sibedge]

why are you dependent on the actual object not being modified?

I have many tests where the connection object is passed around, persisted and tested against the original, to make sure that at any point we are trying to establish the correct connection.

Now that the original connection object suddenly mutates, we no longer can figure out whether it still represents the same connection or something else. It is an integrity break.

[brianc]

I'm publishing pg@6.0.0 & I'll document the changes in more depth. I still am not exactly sure on what you're describing - reference equality of a client in a pool remains the same between checkouts - but hey, now we're safe cause it's a major version bump. 😄

[sibedge]

Ok, another example here...

At least previously, your own connection pool was using the connection object serialized into a string as the key to look up the Client.

There are many higher-level libraries out there that use the connection object to figure out when something has changed about the connection, and then act upon it, with all kinds of overhead.

Now they all will break, i.e. they all will detect that the connection object has changed, time to do something, like maybe even reinitialize everything in the system.

[brianc]

Yah you're spot on about that - I tried to document that a bit more in the new changelog I just updated. That api was actually never supposed to be public, but I wasn't watching the WIKI & it was added! (:scream:) noticed that today! So you're spot on. Hopefully doing a major version instead of a minor version puts the appropriate amount of warning signs out on the road that things are different! I really appreciate you jumping on this as fast as you did - sometimes it sucks giving bad news about breaking changes but really helps keep me honest. One thing I've tried to do over the 5 years of node-postgres existing is break backwards compatibility as little as possible and only for a good reason - without you letting me know when that's happened sometimes its hard for me to tell! So..thanks!! 🙇

[sibedge]

I really appreciate you jumping on this as fast as you did.

I've been contributing as much as I could for the last 2 years. Maybe not always politely enough, sorry for that. Please restore access to my regular account vitaly-t, it makes things awkward for my continued development of pg-promise, which today by the way is a major distribution source for your library as well. For example, yesterday, it saw a new record of 13K downloads a day on NPM, which is substantial ;)

[brianc]

@sibedge - I will restore your access, but I'd like to go over a few things real quick hopefully we can agree to going forward.

Please be kind, patient, and grateful when people open up issues here. Open source can be scary and daunting to new folks, its definitely scary for me on some projects, and anything that would serve to alienate them or put people off of contributing, to me, is a major no no.

If I get too many issues opened up as duplicates or lacking code formatting that's probably a bug in my documentation on how to submit issues & I should better document the process. I've had to moderate a few things you said as I felt they were a touch unfriendly to people who are looking for help or advice on what might be a very complex module for them to use, which is ultimately why I blocked the vitaly-t account.

I realize it can be frustrating if there are duplicate issues opened or questions about seemingly (to you) trivial issues, but if you're feeling frustrated don't worry about pitching in on those issues, I will eventually get to them as I have over the years. 😄

I definitely have appreciated your help here on reporting issues you've found through your pg-promise library, and overall node-postgres quality has improved because of you. I just cannot have people feeling rejected when they come to this repo for help. If you know the answer to their bug by all means pitch in, and I'm always happy to field bug requests and questions from you as well.

I do this in my spare time for free & sometimes my time is limited and its easier to just block than engage in trying to course correct - hopefully we're on the same page now & we can continue to make FOSS better side by side! If you'd like I can provide feedback on issues or privately if you send me your email address next time instead of just removing access! ❤️

[sibedge]

Cheers, buddy!

[vitaly-t]

@brianc Fresh contribution: #1060 😉