Hacker News Reader

Comment by diminish | Hacker News Reader

Why a major release soon after another one? Fast release cycles?

Semi-recent change in policy:

> Starting with PostgreSQL 10, a major version is indicated by increasing the first part of the version, e.g. 10 to 11. Before PostgreSQL 10, a major version was indicated by increasing either the first or second part of the version number, e.g. 9.5 to 9.6.

* https://www.postgresql.org/support/versioning/

This is to help indicate that an in-place upgrade is not possible. To put it simply, you have to do a dump/restore to go from 11.x to 12.x (there are 'advanced' ways around this).

There was some confusion in the past with new users about why something like that was needed for "only" a 'minor' update of going from 9.5 to 9.6.

According to the release notes, dump/restore is not necessary to get to 12 — pg_upgrade works.

You're generating a new set of data files, which IMHO is the same principle. (There's nothing wrong with this, it's just telling folks you can't just drop in a bin bin/postgres and run it blindly.)

That's not how pg_upgrade works or has ever worked. The only data files that are regenerated are those used for system catalogs.

The policy change for version numbers more or less happened because we could never justify bumping the most significant number for the latest stable release. It had become meaningless.

That was never true for major version upgrades:

e.g.

9.4.x -> 9.5.x

9.5.x -> 9.6.x

9.6.x -> 10.x (they changed versioning since 10.x)

10.x -> 11.x

11.x -> 12.x

and so on

You couldn't just drop new version and assume it will work, the database needed to be converted to new format, pg_upgrade tool was created for this operation. By default it generates a new database in new folder. There's also a flag that uses hard link for files that didn't change between versions (it usually only takes a minute or less), but with the caveat that if upgrade is not successful and you run the new version of the database, you'll have to use backup to restore old version (since the new version might modify the files).

There's also pg_dump/pg_restore, but this is the slowest way.

The releases may seem more major than they did in the past because PostgreSQL dropped one part of its version number with version 10.

11 is to 12 roughly as 9.5 is to 9.6, not as 9.0 is to 10.0

PostgreSQL has followed the current schedule of yearly major releases for about 10 year.

That doesn't add up. I've been using PG for over 15 years and it was around before that.

Before v10, even the minor version number increase was a major release (i.e. 9.1 -> 9.2).

This interpretation makes sense to me (starting from 6)

Not sure what doesn't add up? While PostgreSQL is certainly around longer than 10 years, the release schedule was somewhat random until ~10 years ago. Since then the project sticks to a yearly schedule, with one major release per year, usually in September/October.

12 - 6, over 15 years makes me think the major should be 21. But counting minor numbers makes the cadence work as another comment states

Before roughly 10 years ago there was no formal release schedule but in practice it was roughly every 1 to 1.5 years, so people decided to formalize the process and do strictly yearly releases.

Today's news is about PostgreSQL 12 GA release. The news you may have seen recently was about few Beta releases in last few months and an RC release last week.

The release was scheduled and planned for quite some time.

Reply on news.ycombinator.com