Re: The case for version number inflation - Mailing list pgsql-advocacy

From Darren Duncan
Subject Re: The case for version number inflation
Date
Msg-id 51302703.4030709@darrenduncan.net
Whole thread Raw
In response to The case for version number inflation  (Josh Berkus <josh@agliodbs.com>)
Responses Re: The case for version number inflation
List pgsql-advocacy
Although likely due to a coincidence, I have seen that Postgres seems to
increment its first digit like clockwork every 5 years, and always changes when
we'd otherwise have a 5 in the second position.

So 8 instead of 7.5, 9 instead of 8.5, so if we continue this, the next releases
would be 9.3, 9.4, and then 10 instead of 9.5.

Prior to that, there was a 6.5 and then 7 instead of 6.6, but that's almost the
same amount.

My understanding is that the major feature change which spawned a first number
increment per version was:

* 9.0 was built-in replication support
* 8.0 was the ability to run natively under Windows rather than needing Cygwin
* 7.0 I'm less clear on, probably adding foreign key support I would guess

So was foreign key support a more major change than other things in 6.x or 7.x
such that it led to a first digit change?  Or was the version change more
arbitrary at that time?

Going forward, if we wish to follow the precedents set before, what kind of new
feature would be major enough, relative to others, to warrant a 10?  If in
doubt, I'd say just keep incrementing 9.x, or arbitrarily switch at 9.5.

-- Darren Duncan


pgsql-advocacy by date:

Previous
From: "Gilberto Castillo"
Date:
Subject: Re: The case for version number inflation
Next
From: Josh Berkus
Date:
Subject: Re: The case for version number inflation