Policy request: Only use even database version numbers

[mcclure]

This is a little arcane, and it's entirely possible it will never benefit anyone but me. But, it is low-cost to implement…

Motivation

I don't use mainline Tusky. I use a personal fork with some idiosyncratic patches. Every major release of mainline Tusky, I re-base my patches on top of the new release. This has worked fine so far. But when v24 releases, I will have a problem. My v23 includes a patch which changes the database format, and so it introduces a database version 52. But when "real" Tusky v24 comes out, it will introduce its own database version 52. And that will result in not only a conflict, but also a big awkward upgrade issue. Either the migration to REAL-52 will be done wrong, or I will have to patch v24 so REAL-52 becomes 53. But then someday Tusky will bump to version 53, and then I'll have to remember that REAL-52 is ANDI-53 and REAL-53 is ANDI-55 and REAL-54 is… you see the problem? It will get more and more confusing with time.

Request

Beginning with v24, introduce a policy that Tusky database-version numbers are always even. This will help fork-users like me, because it will mean the even numbers are reserved for Tusky mainline and the odd numbers are reserved for forks. A fork maintainer can drop any database changes into the odd numbers and when the next version comes, they only have to change the migration number to bump from odd to even, they don't have to change the new database number's number.

(Making the database number always odd, and reserving even numbers for forks, would also solve the problem, and would coincidentally work even better for me, but I think "even only" is less confusing for the Tusky mainline and the most important thing is to keep Tusky mainline understandable.)

[Lakoja]

(Just as an idea: We could use "date-based numbers" like for the settings schema. E.g. database version 2023073012.)