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.
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
