Re: 10.0

Поиск
Список
Период
Сортировка
От Greg Sabino Mullane
Тема Re: 10.0
Дата
Msg-id 89a6cf10013a9eecc20c04f6b295bbab@biglumber.com
обсуждение исходный текст
Ответ на Re: 10.0  (Martín Marqués <martin@2ndquadrant.com>)
Ответы Re: 10.0  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: 10.0  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


> Wasn't there some controversy about switching to major.minor versioning
> this in -advocacy?
>
> http://www.postgresql.org/message-id/ee13fd2bb44cb086b457be34e81d5f78@biglumber.com

I proposed in that thread that we always increment the first number, 
never increment the second number, and increment the third exactly as we do 
now for bugfix releases.

I think moving to a two-number format is a mistake: what exactly will 
PQserverVersion() return in that case? But I understand people have a hard 
time swallowing the "never change the middle number" portion of this idea.

Thus, here's a slight variation on that theme: what if we simply reversed the 
expectations of bumping the first number, and put the onus on people to 
change the *middle* number? Thus, the next release by default will be 10.0.0, 
the one after that will be by default 11.0.0, and so on. We can reserve the 
middle number for "lesser" releases - which may never happen - but at least 
we will have a mechanism to provide for them. So rather than the current spate 
of messages like this:

"This should be called 12.0 because of cool feature X and reason Y"

we would get the rare message like this:

"We don't really have much for this release, maybe it should just be 11.1?"


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

iEYEAREDAAYFAlc34/UACgkQvJuQZxSWSsgQLgCeJS9v69R5C3BJxNy2ih1P2Tk8
xngAn0UQoSn6y3iOwMr5aHSKzuBh+3Xn
=wzw4
-----END PGP SIGNATURE-----





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

Предыдущее
От: Anderson Carniel
Дата:
Сообщение: Re: Losing memory references - SRF + SPI
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 10.0