Re: The case for version number inflation

From: Darren Duncan <darren(at)darrenduncan(dot)net>
To: pgsql-advocacy(at)postgresql(dot)org
Subject: Re: The case for version number inflation
Date: 2013-03-01 03:56:51
Message-ID: 51302703.4030709@darrenduncan.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Josh Berkus 2013-03-01 18:19:37 Re: The case for version number inflation
Previous Message Gilberto Castillo 2013-02-28 19:41:34 Re: The case for version number inflation