Re: The case for version number inflation

Поиск
Список
Период
Сортировка
От Greg Sabino Mullane
Тема Re: The case for version number inflation
Дата
Msg-id 004dd9a46fa21d1e59e0996c87b093c8@biglumber.com
обсуждение исходный текст
Ответ на Re: The case for version number inflation  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-advocacy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


Josh Berkus spake:
> I'm beginning to think that no matter how much *I* like our version
> numbering scheme, it's hurting us with users because they see the last
> three releases as "version 9".  One of PostgreSQL's best features is
> that we do a new major release every year, meaning that the database is
> improving greatly every year.  To the vast majority of the population,
> our version numbering scheme doesn't tell that story.

Do you have more than anecdotes to back that up? Not bumping the major
number every release is the norm, not the exception (in the tech world).
More to the point, does it really hurt our uptake to be on version 9.2
instead of version 12?

Simon Riggs wrote:
> Big version numbers imply incompatibility, which mostly we don't do
> and scaring people isn't part of the objective here. Yes, some people
> make the mistake of thinking nothing has changes, but we wouldn't want
> the opposite either - people thinking there was change and giving up
> "Oh damn! I'm only compatible with Postgres 8.4, oh well but at least
> it has MyGrandad 11 support so we'll use that instead".

Of course, we actually are not consistent at all. 7.3 to 7.4 should have
been a major change, and was not. And other major jumps, while adding
lots of new features, certainly did not have incompatibility issues.
Other than a major protocol change, it's hard to argue than *anything*
automatically warrants a major version bump.[1] The key word here
being 'automatically'.

> We should move to 10.0 only when we have something big to say.
> Incrementing the big number every release prevents us from flagging
> major changes to the outside world.

Agreed.

> Most importantly, if we were going to call this release 10.0, I'd feel
> a lot happier committing certain more risky looking patches. Deciding
> this at the last minute is kindof confusing there.

This is putting the cart before the horse, isn't it? Let's commit all
we can, and *then* make the decision as to how worthy the changes are
for a major number bump.

[1] Upon reflection, in-place upgrade qualifies

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201303021402
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlEyTOUACgkQvJuQZxSWSsierACg/KD+TC+1I4Hjt3XOBTQ7jaUv
vEUAnR3VGy5/AXhuDgS4Kdv5vru9U+SZ
=VAra
-----END PGP SIGNATURE-----




В списке pgsql-advocacy по дате отправления:

Предыдущее
От: Hans-Jürgen Schönig
Дата:
Сообщение: Re: The case for version number inflation
Следующее
От: Bruce Momjian
Дата:
Сообщение: Open Database Camp in Cambridge, MA, USA is looking for speakers