Define DB_VERSION format

[abitmore]

User Story
As a developer, usually we need to update DB_VERSION to force a replay when updated database schema (e.g. 9af57a8, dd532f7). When developing different features in multiple branches, usually there will be conflicts on db_version. However, when these is a conflict, the best approach is NOT to accept changes in either branch, instead, it's best to update db_version to a new one. Putting a number or a date in db_version is not intuitive enough to avoid merging issues, see #1609 (review).

Impacts
Describe which portion(s) of BitShares Core may be impacted by your request. Please tick at least one box.

• API (the application programming interface)
• Build (the build process or something prior to compiled code)
• CLI (the command line wallet)
• Deployment (the deployment process after building such as Docker, Travis, etc.)
• DEX (the Decentralized EXchange, market engine, etc.)
• P2P (the peer-to-peer network for transaction/block propagation)
• Performance (system or user efficiency, etc.)
• Protocol (the blockchain logic, consensus, validation, etc.)
• Security (the security of system or user data, etc.)
• UX (the User Experience)
• Other (please add below)

Additional Context (optional)

CORE TEAM TASK LIST

• Evaluate / Prioritize Feature Request
• Refine User Stories / Requirements
• Define Test Cases
• Design / Develop Solution
• Perform QA/Testing
• Update Documentation

[ryanRfox]

I suggest to have the DB_VERSION match the outcome of #1173 for Release Version Numbering.

[abitmore]

We don't force replay on every new release, so it's unnecessary to update DB_VERSION every time.

[pmconrad]

DB_VERSION currently has no semantic other than "it changed" or "it didn't". A simple date stamp should be sufficient. Rule for merge conflict: bump to current date.

[oxarbitrage]

I agree here that just a date will make it and it is more intuitive than a number for conflicts.

YYYYMMDD can be used and i am tempted to say for the releases the format should have full year as well, for example current release tag 2.0.190219 is confusing, 2.0.20190219 is better but that is maybe more a comment to #1173 .

I suggest to leave this issue open as a reminder until we need to bump the database again at any branch, use the timestamp format then and close the issue.

[ryanRfox]

Rule for DB_VERSION format: YYYYMMDD
Rule for merge conflict: bump to current date (YYYYMMDD)

Closing