5 ms·

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

amitlan 7y ago
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.
jeltz 7y ago
PostgreSQL has followed the current schedule of yearly major releases for about 10 year.
- edoceo 7y ago
  That doesn't add up. I've been using PG for over 15 years and it was around before that.
  - pgaddict 7y ago
    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.
    - edoceo 7y ago
      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
  - vetinari 7y ago
    Before v10, even the minor version number increase was a major release (i.e. 9.1 -> 9.2).
    - edoceo 7y ago
      This interpretation makes sense to me (starting from 6)
  - jeltz 7y ago
    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.
ellisv 7y ago
The release was scheduled and planned for quite some time.
chousuke 7y ago
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
throw0101a 7y ago
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/ 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.
- wrs 7y ago
  According to the release notes, dump/restore is not necessary to get to 12 — pg_upgrade works.
  - throw0101a 7y ago
    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.)
    - petergeoghegan 7y ago
      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.
    - takeda 7y ago
      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.

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.

jeltz 7y ago

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

edoceo 7y ago
That doesn't add up. I've been using PG for over 15 years and it was around before that.
- pgaddict 7y ago
  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.
  - edoceo 7y ago
    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
- vetinari 7y ago
  Before v10, even the minor version number increase was a major release (i.e. 9.1 -> 9.2).
  - edoceo 7y ago
    This interpretation makes sense to me (starting from 6)
- jeltz 7y ago
  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.

ellisv 7y ago

The release was scheduled and planned for quite some time.

chousuke 7y ago

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

throw0101a 7y ago

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

wrs 7y ago
According to the release notes, dump/restore is not necessary to get to 12 — pg_upgrade works.
- throw0101a 7y ago
  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.)
  - petergeoghegan 7y ago
    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.
  - takeda 7y ago
    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.