title: Flyway: How to handle v1.x style versions (e.g 1.2.0.a) in migration filenames?
body: <p>Currently we are using Flyway 2.0.3 and finally do our homework to upgrade to the latest version of Flyway. </p>
  
  <p>I am aware of the step to go to 2.3.0 first. With that step we adjust the version schema of Flyway. </p>
  
  <p>Now I am looking for a way to migrate our sql migration files with the following naming pattern: </p>
  
  <pre><code>V1_2_0_a__AddFileDescription-oracle.sql
  V1_2_0_b__ModifyFileDescription-oracle.sql
  ...
  V1_3_0_a__DoSomeStuff-oracle.sql
  </code></pre>
  
  <p>With the drop of the support of non-number characters I receive the known error <code>com.googlecode.flyway.core.api.FlywayException: Invalid version containing non-numeric characters. Only 0..9 and . are allowed. Invalid version: 1.2.0.a</code></p>
  
  <p>Is there any best practice migration guild for that old version available?<br/>
  Any suggestions are very welcome. Thanks,<br/>
  J0er9</p>
  
  <p>Update:
  Renaming the migration files as suggested do not solve the issue. 
  With renamed migration files the parsing of the sql files succeeds. But in the next step Flyway reads the already applied migrations from the meta data table ("schema_version" in my case). This fails because the old pattern version numbers are still present in the database. This ends up with</p>
  
  <pre><code> org.flywaydb.core.api.FlywayException: Version may only contain 0..9 and . (dot). Invalid version: 1.2.0.a
  at org.flywaydb.core.api.MigrationVersion.toBigInteger(MigrationVersion.java:258)
  at org.flywaydb.core.api.MigrationVersion.tokenize(MigrationVersion.java:241)
  at org.flywaydb.core.api.MigrationVersion.&lt;init&gt;(MigrationVersion.java:82)
  at org.flywaydb.core.api.MigrationVersion.fromVersion(MigrationVersion.java:71)
  at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory$2.mapRow(JdbcTableSchemaHistory.java:202)
  at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory$2.mapRow(JdbcTableSchemaHistory.java:184)
  at org.flywaydb.core.internal.jdbc.JdbcTemplate.query(JdbcTemplate.java:367)
  at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory.refreshCache(JdbcTableSchemaHistory.java:184)
  at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory.allAppliedMigrations(JdbcTableSchemaHistory.java:174)
  at org.flywaydb.core.internal.info.MigrationInfoServiceImpl.refresh(MigrationInfoServiceImpl.java:131)
  at org.flywaydb.core.internal.command.DbValidate$2.call(DbValidate.java:138)
  at org.flywaydb.core.internal.command.DbValidate$2.call(DbValidate.java:126)
  at org.flywaydb.core.internal.jdbc.TransactionTemplate.execute(TransactionTemplate.java:74)
  at org.flywaydb.core.internal.command.DbValidate.validate(DbValidate.java:126)
  at org.flywaydb.core.Flyway.doValidate(Flyway.java:267)
  </code></pre>
  
  <p>Is there some kind of fixing logic in place? Or can this be achieved by Flyway.repair() call? If I understand repair() right, it would wipe the not longer available migrations from the meta data table. In my case the old migrations would not be longer available due to the renaming.</p>