Re: Just for fun: Postgres 20?

On Tue, Jun 2, 2020 at 2:45 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Jun 1, 2020 at 3:20 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)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