On Mon, Jun 1, 2020 at 3:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > As has already been pointed out, it could definitely happen, but we > > could solve that by just using a longer version number, say, including > > the month and, in case we ever do multiple major releases in the same > > month, also the day. In fact, we might as well take it one step > > further and use the same format for the release number that we use for > > CATALOG_VERSION_NO: YYYYMMDDN. So this fall, piggybacking on the > > success of PostgreSQL 10, 11, and 12, we could look then release > > PostgreSQL 202009241 or so. > > But then where do you put the minor number for maintenance releases?
Oh, well that's easy. The first maintenance release would just be 202009241.1.
Unless, of course, we want to simplify things by using the same format for both parts of the version number. Then, supposing the first maintenance release follows the major release by a month or so, it would be PostgreSQL 202009241.202010291 or something of this sort.
Since there is a proposal to have a 64-bit transaction ID, we could rather have a 64-bit random number which could solve all of these problems. :P
And then if I ask my customer what Postgres version is he/she using, it could be a postgres fun ride.
It's hard to agree on anything around here but I suspect we can come to near-unanimous agreement on the topic of how much merit this proposal has.