On Wed, Feb 12, 2020 at 11:25 AM Juan José Santamaría Flecha
<juanjo.santamaria@gmail.com> wrote:
> On Wed, Feb 12, 2020 at 3:47 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yeah; I don't think it's *that* unlikely for it to happen again. But
>> my own principal concern about this mirrors what somebody else already
>> pointed out: the one-major-release-per-year schedule is not engraved on
>> any stone tablets. So I don't want to go to a release numbering system
>> that depends on us doing it that way for the rest of time.
>
> We could you use YYYY as version identifier, so people will not expect correlative numbering. SQL Server is being
releasedevery couple of years and they are using this naming shema. The problem would be releasing twice the same year,
buthow likely would that be?
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. As catversion.h wisely points out,
there's room to hope that we'll never commit 10 independent sets of
catalog changes on the same day, and I think we can also hope we'll
never do more than ten major releases on the same day. Admittedly,
skipping the version number by 200 million or so might seem like an
overreaction to the purported unluckiness of the number 13, but just
think how many OTHER unlucky numbers we'd also skip in the progress.
/me runs away and hides.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company