Validate datetime for version.

[dereuromark]

Resolves #2248

For legacy reasons and BC on the test harnesses I allowed the 0 to pass for now as well.
I think thats fair since most mistakes would happen with actual datetime values.

[MasterOdin]

I've debated on if the appropriate place to put this is as a runtime check within initialization the migration, vs within the getMigrations method in which the migrations are initialized (and which all other methods use to get the list of migrations). I'm somewhat leaning towards the latter with the concept that if some alternative versioning scheme was desired, it'd probably be easier to support via the getMigrations method where we have access to the config object to determine said alternative versioning strategy.

Thoughts?

For legacy reasons and BC on the test harnesses I allowed the 0 to pass for now as well.

I'm curious what legacy reason beyond test harnesses exist to support 0 as a version. I feel like having support for this just for tests seems wrong, where the tests should be updated as it's maybe a bug for production to allow this?

---

I do like the approach here of only validating that the version integer is a valid date string, and not putting limits on what the allowed range of dates is, as I think that has the potential to be limiting for less value.

[MasterOdin]

A follow-up here would be to validating that the various pieces of the string are all valid, e.g. that don't have 00 or 13 for MM, potentially including also complexity in not allowing invalid dates (e.g. no 30 for MM == 02).

[dereuromark]

Sure, but then it wouldnt fit in a "minor" release probably as people could have existing invalid ones that are valid in range (sorting).
So for now I would like to keep it as is, but in the next major we could try to limit it to a more sane value in general.

[dereuromark]

where the tests should be updated as it's maybe a bug for production to allow this?

could be a follow up if you want to further narrow the possible valid values.

[dereuromark]

I pushed the update, was a quick write-up.
Hopefully we can get this in now asap to avoid people running into this like me and others did.

[MasterOdin]

Easy enough to move this check to somewhere else if we decide we need to down the road without breaking BC I think.

I do think this check does break BC though in that it's possible to bypass the date version naming scheme that phinx uses, and just use any number you wanted (e.g. having a counter), though you'd just have to manually create each migration. Not sure if anyone is doing that, so probably fine to just merge it into the next 0.15.x release, and easy to revert if there's enough pushback, or minimally just have them override the base AbstractMigration class.