feat: add SetAllowZeroVersion to support version 0 migrations

[paulo]

Tools like Drizzle ORM generate zero-prefixed migration files (e.g., 0000_sticky_sunset_bain.sql). Goose currently rejects these because it enforces version >= 1 everywhere and uses version 0 as a sentinel row in the version table to mark "table initialized."

This PR adds SetAllowZeroVersion to relax that constraint. When enabled, the sentinel row is inserted at version -1 instead of 0, freeing version 0 for real migrations. It has the limitation that it only works for new databases. Existing databases with sentinel at 0 are not automatically migrated — version 0 would still collide with the sentinel.

I tried to keep the impact surface as minimal as possible to make it easier to review. Let me know what you think, I'm happy to update the implementation as needed.

[mfridman]

Curious, what problem does this solve? I.e., is there some practical limitation you're running in to?

[paulo]

Curious, what problem does this solve? I.e., is there some practical limitation you're running in to?

I'm currently using drizzle ORM to auto-generate some migration files (this is a smaller part of a larger system), and because those migrations start from 0 (e.g., 0000_sticky_sunset_bain.sql), they never get applied when executed with goose.

The options would be to either:

• rename those migrations to start from 1, which I think would be confusing in the long term
• propose this change so migrations can start from 0 (which seems to be the trend on newer tooling)

So not as much as a limitation per-se, but more of a way to integrate nicely with other tools.

[paulo]

@mfridman is this something you'd be willing to incorporate into the tool? (thank you for maintaining it 🙏)

[mfridman]

Thanks for the context.

I've been looking back at prior issues where we've discussed removing (not replacing) the zero version altogether. Which I think is another way to support this request.

Relevant, #302 (comment) and #187 (review)

[paulo]

Thanks for the context.

I've been looking back at prior issues where we've discussed removing (not replacing) the zero version altogether. Which I think is another way to support this request.

Relevant, #302 (comment) and #187 (review)

There's some code on migration parsing that prevents migrations with a numerical lower than 1 (see my changes), but if we account for that, it should work 👍

[mfridman]

I think that's the right direction long term. The zero version was intended to be a marker for "the schema history table is configured properly, we know it exists", but we can detect table existence without a sentinel row, so I'd prefer to remove it entirely rather than shift it to -1. That frees up version 0 for real migrations without any opt-in flag.

The tricky part is backwards compat (as you pointed out). Existing databases already have a version 0 sentinel row. We'd need to handle that gracefully, either by ignoring it or cleaning it up. (needs a bit of thought).

ps. I might be absent ~days, so make not reply, but overall the direction seems right.

[paulo]

The zero version was intended to be a marker for "the schema history table is configured properly, we know it exists", but we can detect table existence without a sentinel row, so I'd prefer to remove it entirely rather than shift it to -1. That frees up version 0 for real migrations without any opt-in flag.

Is this something that you're planning on working on, or should I give it a shot?