Re: The case for version number inflation
От | Darren Duncan |
---|---|
Тема | Re: The case for version number inflation |
Дата | |
Msg-id | 51302703.4030709@darrenduncan.net обсуждение исходный текст |
Ответ на | The case for version number inflation (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: The case for version number inflation
|
Список | 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 по дате отправления: