Hybrid versioning broken?

[sjernigan]

I understand the theoretical need for the sequential ordering of migrations in prod (though I've never had the problem with my small dev team). I'm definitely aware of merge conflicts in development and the need for timestamp-based versioning. I can even imagine a process where the 'fix' command could bridge these two worlds. However, I don't see how goose's timestamped versioning works to solves merge conflicts in development. Here's the scenario that is seriously broken in out workflow.
1 Bill creates a migration on 4/1
2 Susan creates a migration on 4/2 and commits it master
3 Jill picks up Susan's migration and runs it
4. Bill merges his branch into master
5. Jill rebases or starts a new branch
5. goose up for Jill does not run Bill's migration or fail because it's only looking for migrations numerically greater than Susan's

I think the previously given answer is I have to down migrate to 3/X then migrate up. In my opinion, that puts a lot of burden on each developer. In my world, 99.99% of the time I would prefer it to just apply Bill's migration. I could potentially see a flag for the other .01% so it just fails. However, I'm struggling to see a scenario that it should just quietly complete the up migration and do nothing.

Before we get any farther, let me say that I understand this is your project and it's reasonable for you to have implemented inline with your process. AND, I appreciate your ongoing effort and time in making something public. But my real question is, "Is there any appetite to make goose work for environments like mine?"

[VojtechVitek]

cc @1vn

[1vn]

I think it's necessary to have the data schema match the branch migration, which is why we expect engineers to want to down migrate on branch changes. However, I also don't see why we can't add an option to let you explicitly only use sequential versioning to opt out of this mantra. @VojtechVitek thoughts?

[VojtechVitek]

@1vn didn't we discuss the "strict mode" by default, from which you could opt-out? That could work.

[zmoazeni]

I'm coming at this with a very similar perspective as @sjernigan. I would very much prefer just to apply Bill's migration and call it a day. I'm sure there are some environments where this scenario fails, but that has worked well for my teams in Rails environments for years.

Is there a form of a PR that I can submit to allow that functionality? Even it amounts to an extra option that we have to pass to say "run missing gaps in migrations" as to not change existing defaults so it doesn't step on the toes of your current process?

Running up right now does not error. it simply ignores any gaps, and you wouldn't know that unless you run status.

% goose postgres "postgres://postgres:postgres@localhost:5432/testmigrations?sslmode=disable" status
2019/05/17 23:18:47     Applied At                  Migration
2019/05/17 23:18:47     =======================================
2019/05/17 23:18:47     Sat May 18 03:16:23 2019 -- 20190517231044_first_migration.sql
2019/05/17 23:18:47     Pending                  -- 20190517231323_second_migration.sql
2019/05/17 23:18:47     Sat May 18 03:16:23 2019 -- 20190517231327_third_migration.sql

% goose postgres "postgres://postgres:postgres@localhost:5432/testmigrations?sslmode=disable" up
2019/05/17 23:24:52 goose: no migrations to run. current version: 20190517231327

% echo $?
0

[bugzpodder]

@sjernigan @zmoazeni I've been using this fork with --include-missing flag and it solves this exact problem. See #183

[mfridman]

Out of order migrations have been added in #280

Supports missing (out-of-order) migrations with the -allow-missing flag, or if using as a library supply the functional option goose.WithAllowMissing() to Up, UpTo or UpByOne.

Thanks for all the feedback.