-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release v1.1.6 #1277
Comments
@meiji163 @rashiq @timvaillancourt wondering if you all can consider cutting a release per the above? |
It should be fixed in #1322. I'll work on a release this week |
release is live! https://github.com/github/gh-ost/releases/tag/v1.1.6 |
Hi there!
We actively use gh-ost at Gusto, we built a tool that wraps gh-ost for our use case. We've maintained a fork on and off over the years, and got our largest change, the logging interface, upstreamed several years ago. However, we'd really like to get back on upstream.
I noticed in the release notes for v1.1.5 that it was created off v1.1.4 with some commits cherry-picked from
master
. Seems this has been the case for the last few releases.In our effort to get back to upstream gh-ost, we discovered that #888 introduced a bug that we caught in our integration tests. The issue is exactly as described in #1171. This change has been present in every version of gh-ost since v1.1.1. However, the change was reverted in the latest commit on master.
In addition to the latest commit, we'd really like to get a release cut that includes this small change I contributed last November.
Ideally, we'd like to have
master
back in a state that it can be released more frequently. As mentioned, the release notes indicate, "as it [master] contains a known issue that is currently being investigated". Can you shed light on that issue? I can report that the integration tests for our tool pass on the latest commit on gh-ostmaster
, but we wouldn't want to use that without understanding the issue being investigated.As an alternative, would you consider cutting a release that cherry-picks #1180 and #1194?
We really appreciate your consideration and the work you all do to make this tool a viable solution for safe schema migrations. Let us know if there's anything else we can do to support it!
Thanks,
Nick
The text was updated successfully, but these errors were encountered: