On Tue, Jun 2, 2020 at 2:45 PM Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Jun 1, 2020 at 3:20 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@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. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > > -- Regards, Avinash Vallarapu
