Version confusion

[spficklin]

I'm finding the version numbers we attach to our Flyway migrations a bit confusing for these reasons:

• Flyway migrations have a prefix of 1.3.3 but the current Chado version is 1.31. What is the final 3 for? Assuming it refers to the 3rd number in the Chado version, what happened to 2?
• We are incrementing Flyway version with a 1.3.3_XXX number. So why the extra .3 if we are incrementing the _XXX?
• We are making changes in the 1.4 branch. But technically if the version number is 1.3 shouldn't those be part of a 1.3x branch?

Another now confusing issue is that previously, the third number in the Chado version was incremented if there were changes to the non-schema code. With PR #100, the non-schema code was moved out. So, now the reason for incrementing that last number is gone.

I think how we do versioning in Chado will need some discussion, but to help reduce confusion what if we stopped using the 1.4 branch and instead used a 1.3x or 1.3.x branch? Then when we make a 1.4 release we move to the 1.4.x branch. Alternatively, we could just simply and make all changes in a dev branch.

[scottcain]

Blame @bradfordcondon :-)

But yes, I agree that it's confusing and warrants discussion.

[bradfordcondon]

very funny @scottcain

The simple answer here is you're right: I should have started naming them as 1.31__01, 1.31__02 etc per your naming conventions. Up for debate if the script version should match the intended upcoming release or the latest release or what it looks like I did, which is the next sequential minor release. Buuuut.....

Looking at the schema history it honestly looks to me like that release 1.31 is an implied 1.3.1. I imagine this was my thought process:

current version is 1.31 which is equivalent to 1.3.1. Next minor release that we'll put the script in is 1.3.2, 1.3.3 etc. we'll also start working on the next major release which is 1.4.

Suggestion: why not use Semantic Versioning 2.0 for versioning
guidelines, so its an adopted standard you dont hae to think about.

This means (from those docs):

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards compatible manner, and
• PATCH version when you make backwards compatible bug fixes.

I also think picking a single dev branch, and minting a release by merging to master and creating a git tag so your github's release page update, is the way to go. Since you dont want the flyway versions to change, makes sense to me that you would do "upcoming next release" IE 1.3.3__ (or 1.33___, if you dont like semver), and then, when you mint 1.4 and someone wants to upgrade to it, they can use flyway which will auto run all scripts up to 1.4 .