LWN: Comments on "Berkus: Changing PostgreSQL Version Numbering"

Berkus: Changing PostgreSQL Version Numbering

alvieboy — Sat, 21 May 2016 18:42:25 +0000

Or "less" version numbering...

Alvie

Berkus: Changing PostgreSQL Version Numbering

flussence — Sat, 21 May 2016 00:56:33 +0000

People complain about systemd version numbers? I guess they're too young to have heard of xterm then...

Berkus: Changing PostgreSQL Version Numbering

micka — Fri, 20 May 2016 09:55:11 +0000

That's good, provided no version number ever go above 3 digits. I have trouble efficiently parsing 4 digit numbers.

Berkus: Changing PostgreSQL Version Numbering

moltonel — Fri, 20 May 2016 09:34:53 +0000

From Berkus's post, it seems like the main annoyance with the current scheme is the time lost in debating when to bump the first number. And those debates are only going to get worse as the project matures (less likely to have ground-breaking changes, more feature sets to consider, more contributors to fuel a debate...)

There are other ways to fix this debating issue than to switch to a two-part version number (which is garanteed to confuse existing users and cause bugs in 3rd-party tools). For example let the release manager be the sole decision maker on the subject. Or systematically decide via a community poll when the RC comes out (a good PR opportunity in itself). Set a strict and close deadline for the decision. In any case, state clearly that the decision ultimately isn't very important.

For what it's worth, I really like PG's versioning scheme and have used it to illustrate the quality of PG's development process. It's pretty much semver. It gives an additional "time to upgrade !" hint to people who don't keep on top of regular releases, that a two-part version number wouldn't give.

Berkus: Changing PostgreSQL Version Numbering

mfuzzey — Fri, 20 May 2016 08:05:34 +0000

The wider the scope of application of a piece of software the harder it is to attach a meaning to a numeric version string based on features.

For example when the linux kernel transtionned from 2.6.x to 3.x to 4.x that was not due to any specific major feature but just because "the numbers were getting to big".

The scope of application of the kernel is so large that a major feature for one use case (S390 mainframes for example) can be irrelevant for another (Android phones for example).

Also, as a piece of software matures the new features added tend to be more esoteric for specific niches and less generally important for all users.

For software having interfaces to the outside world in the form of file formats or ABI incompatible changes can provide a good indication of when to upgrade the version.
But even then it can get complicated once the software starts exposing multiple interfaces. Then it can be useful to version the *interfaces* in addition to the software itself (with a given version of the software potentially providing multiple versions of some interfaces) - linux distributions being a case in point - a given version of a distribution may provide multiple versions of some libraries for example.

Not sure what the situation is exactly for Postgre though.

Berkus: Changing PostgreSQL Version Numbering

malor — Fri, 20 May 2016 07:25:07 +0000

Yeah, it seems to me that 'incompatible database format' is a time when you upgrade the X, not the Y.

From there, it doesn't really matter what X is. Assuming that they will never make more than one incompatible format change per year, making X be the year is fine.

Just shooting from the hip, I'd probably try to code it this way:

X: Downtime required for upgrade.
Y: New features, in-place upgrade.
Z: Bugfix release.

So 2016.0.0 might be the next release; if they add features, it would be 2016.1.0, then 2016.2.0, no matter what year it is. A bugfix to the third point release might be 2016.3.1. When they next make a breaking change, it would become, say, 2018.0.0.

The problem with that becomes: if they don't change formats regularly, then they might end up releasing, say, 2016.6.0 in 2024. That's going to create an artificial pressure to look like they're "making progress". Maybe they should just stick with regular numbers for X? PostgreSQL 10.6.0 wouldn't feel falsely dated in 2024.

I'd definitely avoid the Ubuntu-style year/month thing, because that doesn't carry much useful information.

Berkus: Changing PostgreSQL Version Numbering

fredrik — Fri, 20 May 2016 07:09:01 +0000

Heh, as a user I enjoy discussions like these. Version numbers can be both very important and not important at all, at the same time. :)

So, let me bring my brush to the bikeshed: Postgresql should use Semver no matter what.

Even if postgresql never would do any minor releases, i.e the minor version would always be 0, and only the major and patch number would ever change, I still think it would be a good idea to adopt sematic versioning. It's a bit like reducing licence proliferation and recommening projects to stick with GPL, Apache, or MIT. The versioning scheme proposed by Postgresql is close enough to Semver that the gain in diverting from it smaller than the loss of increased proliferation.

Berkus: Changing PostgreSQL Version Numbering

jhoblitt — Fri, 20 May 2016 06:28:32 +0000

This sounds like:

Problem: the versioning scheme does not provide useful information about the level of change to end users
Solution: change to a different versioning scheme that indicates the date of the release?

While I think the real issue is that users, conscious of it or not, pretty much expect a semver-ish version scheme.

Berkus: Changing PostgreSQL Version Numbering

epa — Fri, 20 May 2016 06:11:03 +0000

It has a longer history than that. IIRC both Solaris and GNU Emacs dropped the first part of their version number - in Emacs's case because it never changed.

Berkus: Changing PostgreSQL Version Numbering

ringerc — Fri, 20 May 2016 05:30:06 +0000

I'll be delighted by this change, since I find myself continually explaining to people that "9.x" isn't a meaningful thing to say about PostgreSQL.

You know, if the major-part of the version number doesn't mean anything, we (re)define "major version" as X.Y, and everyone's confused by that, maybe we're doing it wrong?

Strictly the "semantic versioning" approach would be to release 10.0.0, 10.0.1, 10.0.2, 11.0.0, 11.0.1, etc, since in semver terms PostgreSQL does not do minor releases at all. It does bugfix point releases and major releases only. A bit ugly, though less so than our current scheme. We might have to encode it that way anyway in PG_VERSION_NUM etc for compatibility, such that PG_VERSION_NUM for 12.1 is 120001 not 1201.

A change from the IMO obviously wrong X.Y major versioning scheme is a real win for usability IMO.

Berkus: Changing PostgreSQL Version Numbering

cuboci — Fri, 20 May 2016 04:54:01 +0000

I think you misunderstood. It's not changing because of the year but because of the yearly new major release. So in effect, this change would do exactly what you want. The first number would signify a need to pg_dump+pg_restore and the second would say bugfix release without that need.

Berkus: Changing PostgreSQL Version Numbering

dskoll — Thu, 19 May 2016 21:33:33 +0000

I don't like the idea of incrementing the major number just because the year has changed. Right now, all PostgreSQL users know that if the first or second number changes, it means pg_dump+pg_restore or pg_upgrade.

They need to keep that info encoded in whatever new scheme they pick. If it's just major.minor, then the major should change if and only if a pg_dump+pg_restore or pg_upgrade is required.

Berkus: Changing PostgreSQL Version Numbering

intgr — Thu, 19 May 2016 20:48:29 +0000

Oh no! People publicly presenting reasoned arguments for a flat version numbering scheme. If readers buy into this, then that may take away any basis from our beloved complaints about Firefox's and systemd's version numbers!