It's been a while, and some good stuff went in, see here.
Besides coming up with some release notes, I think the following stands out a little this time: we've got what I'd consider a blocking issue, and a somewhat backwards-incompatible change (or at least _action needed_) in a connector:
Anything else? 馃槂
I'll take a look at the serializable stuff today - back from vacation now! I have a theory as to what's going on.
@vito please don't feel pressured. I've just opened this issue to have something tracking our progress, and to share awareness for the various things. 馃槃
@srenatus No worries! I'd like to get to the bottom of it soon mysef.
@srenatus any help needed to drive dex to a new release? Is #1356 the only blocker?
@soggiest thanks for reaching out!
As it stands, we're in a place where our first attempt at fixing #1341 was reverted, and a next attempt (or a stepping stone) is in the works in #1370.
That said, what we have in master _right now_ is no worse than what we have lived with for a long time (as it's not really changed), so I could see us cutting a release now, and continue working on the SQL concurrency bits for the next one.
@soggiest I take it you'd really like to see a release soon? 馃槈
@srenatus I'm fine with using what's in master. I'm a huge proponent of Dex and have used it for various clusters with great success and want to give back to the project however I can.
@srenatus I'm fine with using what's in master. I'm a huge proponent of Dex and have used it for various clusters with great success and want to give back to the project however I can.
So, reconsidering this after a month has passed (sorry for the delay, folks!) -- since the keystone connector is _this close_ (#1374), I'd wait for that PR to land. Having made little process on the SQL transaction front, we're not worse off than before right now; so, we can have a release and keep on pushing that issue.
Waiting for #1347... Sigh
Most helpful comment
:tada: