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
Re: 10.0 |
Список | 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 по дате отправления: