Individual developers and those that merge their PRs should be responsible for developing and testing the `goose down` portion of a migration, this does not change. The whole argument is that relying on goose down for rollbacks is less than ideal because you have to run it 1 time per migration that was applied during an upgrade. This is why Rawlin is proposing a different solution of creating a database snapshot and upgrade time that can be used in case of rollback.
On Tue, Oct 23, 2018 at 10:56 AM Gray, Jonathan <jonathan_g...@comcast.com> wrote: > If we're removing goose down from the downgrade procedure, but still > requiring support for it, doesn't that just make finding issues with it > more difficult since fewer use cases would use that codepath? > > Jonathan G > > On 10/23/18, 10:27 AM, "Dave Neuman" <neu...@apache.org> wrote: > > >>We still need the ability to do a goose down > Rawlin has already stated that we will not be losing this ability. We > will > just be adding the ability to do a wholesale downgrade of the database. > >
