What do you guys think is the best way to handle migrations of a published package?

What do you think is the best way to handle migrations of a published package? Assume you would have to change the database structure inside your package. Would you just add new migrations with the changes like you would do in any other project so the migrations history stays consistent? You would need to accept that your package could then likely come with a bunch of migrations files that essentially only create one or two tables.
Or is it even valid to change the old migration files that have already been migrated in the apps that use your package?
In the past, packages have provided their migrations by letting the developer manually publish the files into the app's migrations directory. But the recommended way today seems to be to let the package's service provider automatically load the migrations from it's vendor folder. This way it makes no real difference how the migrations actually look like and I would just add new migrations if something changes.
Sorry for the scattered thoughts, just let me see what you think..
You already invited:

Majidy El-kindy

Upvotes from:

Adding new migration files seems to be the only sane way so users can upgrade the package

If you wanna answer this question please Login or Register